| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
and declare it in non-public header src/Fl_Scalable_Graphics_Driver.H which also
declares classes Fl_Font_Descriptor and Fl_Fontdesc.
|
|
|
|
|
|
|
|
|
|
These types of boxes frame a background with a rectangular frame of another color.
The previous procedure to draw them was not robust to GUI rescaling creating cases
where space between the border and the background was not drawn.
The new drawing procedure for these boxes first paints the whole area (frame included)
with the background color and next draws the frame over the just painted rectangle.
No uncolored space is possible.
It was also necessary to very slightly modify Fl_Scalable_Graphics_Driver::rect()
used by the Windows and X11 (no Cairo) backends to make sure fl_rect(x,y,w,h)
exactly frames fl_rectf(x,y,w,h) without drawing outside the filled area.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove extra semicolons after function definitions
|
|
|
|
|
|
|
|
This adds fl_rounded_rect and fl_rounded_rectf so the
user can draw rounded rectangles. This uses existing and
optimised code that is rearranged.
|
|
|
|
|
|
|
|
and display-cairo.
|
|
|
|
|
|
|
|
|
|
|
|
platform.
|
|
|
|
|
|
Add includes of system headers in the implementation files
where necessary.
|
|
Fl_Scalable_Graphics_Driver
Most coordinate calculations are done with the new inline function
int Fl_Scalable_Graphics_Driver::floor(int coord)
that is used by both the Windows and X11 platforms.
|
|
|
|
|
|
|
|
Re: Can custom box type functions handle their own high-DPI screen scaling?
|
|
factor.
This new API is a response to this message in fltk.general :
Can custom box type functions handle their own high-DPI screen scaling?
|
|
|
|
|
|
|
|
|
|
The change lets this function enlarge the size only when strictly necessary
for image tiling.
|
|
|
|
|
|
|
|
Restores proper separation of what is in libfltk and what is in libfltk_images
|
