Graphics drivers now use up to 6 virtual member functions to support Fl_Image
drawing in the context of GUI and image rescaling :
virtual void draw_pixmap(Fl_Pixmap *pxm, int XP, int YP, int WP, int HP, int cx, int cy)
virtual void draw_bitmap(Fl_Bitmap *bm, int XP, int YP, int WP, int HP, int cx, int cy)
virtual void draw_rgb(Fl_RGB_Image *rgb, int XP, int YP, int WP, int HP, int cx, int cy)
and
virtual void draw_fixed(Fl_Pixmap *pxm, int XP, int YP, int WP, int HP, int cx, int cy)
virtual void draw_fixed(Fl_Bitmap *bm, int XP, int YP, int WP, int HP, int cx, int cy)
virtual void draw_fixed(Fl_RGB_Image *rgb, int XP, int YP, int WP, int HP, int cx, int cy)
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12828 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The fix is to use the X11 graphics driver's line_delta_ private member variable also when drawing complex
shapes with fl_begin_loop(). The gtk+ scheme does use fl_begin_loop() to draw its frames.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12821 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The docs of class Fl_Image and of Fl_Image::scale() are beefed up.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12784 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Each image has now two sizes implemented as follows:
- the pixel size is stored in private members pixel_w_ and pixel_h_
with public accessors pixel_w() and pixel_h()
- the FLTK size is stored in private members w_ and h_ and read by w() and h()
- when the image is constructed, the two sizes have the same value
- the protected w(int) and h(int) member functions set both FLTK and pixel sizes.
- the public scale(int, int) member function is essentially nothing but
set the FLTK size and don't change the pixel size.
- when the image is drawn, its FLTK size determines how big it is drawn, its pixel
size determines how much data are available to draw it.
FLTK 1.3.4 with FL_ABI_VERSION=10304 contained an equivalent member function
but only for the Fl_Shared_Image class.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12776 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Make clipping methods non-virtual so they can be inlined.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12753 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Back to 16-bit coordinate limit clipping (actually +/- (2**15 - 8).
The clipping range is now constant, symmetrical, and stored in the
driver object.
Also fixed a bug in Liang-Barsky line clipping algorithm.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12744 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This member function transforms the current clip region from FLTK units to pixel units
multiplying FLTK units by the current value of the scale factor to get pixel units.
The current clip region has been, by construction, restricted to the 16-bit coordinate space.
But these data can evade this space after multiplication by the scale factor.
Thus, it's necessary to enforce the 16-bit space here which is done with Fl_Xlib_Graphics_Driver::XRectangleRegion.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12727 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
In FLTK 1.3.x only horizontal and vertical long lines with endpoints
outside the 16-bit coordinate space could be drawn with proper X11
coordinate clipping. Now arbitrary lines are clipped so they can be
drawn with X11 functions.
All rectangles are clipped as well (as in 1.3).
Todo: The code needs better documentation and clipping of polygons,
circles, curves etc. is still missing. The next step should be the
clipping of polygons...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12725 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This is the first commit of X11 16-bit coordinate space (clipping) fixes.
More to follow...
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12722 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Replace compiler/preprocessor/platform macro "WIN32" with "_WIN32".
Replace "WIN32" in text and documentation with "Windows".
Replace "MSWindows" with "Windows".
To do: README.Windows.txt (and maybe other documentation as well)
needs updates.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12655 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This commit also simplifies the platform-dependent support of fl_read_image():
only Fl_XXX_Screen_Driver::read_win_rectangle() contains platform-specific
code to capture pixels from the current window or from an offscreen buffer.
Platform-independent function Fl_Screen_Driver::traverse_to_gl_subwindows()
captures subwindows that intersect with the area fl_read_image() targets.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12653 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This second step replaces FL/x.H with FL/platform.H in all source files.
Dependencies have been adjusted as well.
This commit completes the replacement of FL/x.H with FL/platform.H.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12641 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
With this, most MacOS FLTK app can be scaled with command/+/-/0/ keystrokes.
A scaling problem remains, visible in test/cube, where the "Test" string is not positioned correctly.
GLUT apps can also be scaled (across platforms).
SVG images are re-rasterized after app scaling for optimal drawing.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12594 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Currently src/drivers/OpenGL/Fl_OpenGL_Graphics_Driver.cxx wouldn't
contribute any code to the lib, but it is kept for future extensions.
This file is no longer compiled (see src/CMakeLists.txt and src/Makefile).
Tested (only) under Windows and Linux.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12381 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Each rectangular component of the clipping region is transformed exactly as by Fl_Xlib_Graphics_Driver::rectf_unscaled()
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12272 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Make sure that text length computed without angle is equal to text length drawn with angle.
This property is essential so that rotated text appears at controlled location at both ends.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12244 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Corresponds to STR #3320
1) HiDPI support consists in detecting the adequate scaling factor for the screen on which
FLTK maps a window, and scaling all FLTK units by this factor. FLTK tries to detect the correct
value of this factor at startup (see more details below). Environment variable
FLTK_SCALING_FACTOR can also be used to set this value.
2) Rescaling support consists in changing the scaling factor of all FLTK windows
in reply to ctrl/+/-/0/ keystrokes.
More details for the various platforms :
- X11: Support is very advanced. Some details need still to be improved.
Automatic detection of the correct starting value of the scaling factor works well
with the gnome desktop. The present code contains no support for this on
other desktops. FLTK_SCALING_FACTOR provides a workaround.
-WIN32: Support is incomplete at this point, although many test
applications have partial or complete HiDPI and scaling support.
The current value of the system's scaling factor is correctly detected
at application startup. Apps respond to changes of this value in real time.
Support needs to define the FLTK_HIDPI_SUPPORT preprocessor variable
at compile time. This way, standard builds produce a code with the
default WIN32 HiDPI support, that is, where all graphics goes to an internal
buffer that gets enlarged by the system and then mapped to the HiDPI
display. To experiment with (or develop) the new HiDPI support requires
a modified build procedure in which FLTK_HIDPI_SUPPORT is defined
at compile time. When the support will be complete, the requirement for the
definition of this preprocessor variable will be removed. The present commit
contains support for a single scaling factor. Eventually, per-screen scaling
factors should be implemented, as done for X11.
- MacOS: this commit does not give new HiDPI for this platform.
Eventually, window rescaling in reply to command/+/-/0/ is desirable.
Per-screen scaling factor makes no sense on this platform because
the OS itself takes care of the difference between the resolutions of
traditional and retina displays.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12239 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The X11 platform uses this argument to restore the correct clipping state after
drawing to an Fl_Image_Surface object.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12226 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
See thread "fl_pop_clip: clip stack underflow! warning on X11"
started on Thu, 20 Apr 2017.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12221 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
