| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3278
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 2 - Specific to an operating system |
Subsystem: | MacOS |
Summary: | In retina macos, CGContextDrawImage draws text and image very blurry |
Version: | 1.3-current |
Created By: | cyantree |
Assigned To: | manolo |
Fix Version: | 1.3-current (SVN: v11118) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | cyantree 05:32 Jan 24, 2016 |
| In retina mode, Fl_Quartz_Graphics_Driver::copy_offscreen is blur(src/Fl_Double_Window.cxx). So I solve it. attachment is patch | |
|
#2 | manolo 00:32 Feb 08, 2016 |
| @cyantree: many thanks for your suggestion. As it is, the patch breaks a few things in the FLTK library so it cannot be committed unchanged: try the device and the overlay test programs that don't run well with the patched library.
The problem is that the semantics of fl_create_offscreen(X,Y) is to create an offscreen bitmap of XxY pixels. The patch changes that to create a bitmap twice as wide and high. When the bitmap is then drawn to a surface (say, the display) with a scaling effect, the result is what you want to attain and is correct. But FLTK uses fl_create_offscreen() in other situations where the expected bitmap must be XxY pixels.
Please, state what is exactly the present behavior of FLTK that is not adequate with retina displays, and I will try to improve it.
Also, please, note the new API : Fl_Shared_Image::scale(int width, int height, int proportional = 1, int can_expand = 0) that might be pertinent for you, but that requires compiling FLTK with -DFLTK_ABI_VERSION=10304 | |
|
#3 | manolo 05:10 Feb 08, 2016 |
| Set the severity level to Moderate.
Waiting for a more detailed description of what should be improved. | |
|
#4 | cyantree 07:59 Feb 08, 2016 |
| thanks for your reply.
I find offscreen draw is blur when I port fltk to ios. So I upload the patch. But you are right. the patch is temporarily. As you say, FLTK is not adequate with retina displays. OK. I wait for right patch. You can close this bug report. | |
|
#5 | manolo 09:13 Feb 08, 2016 |
| My opinion is that FLTK supports correctly the Mac OS platform with retina displays when the new Fl_Shared_Image::scale() member function is used to draw images.
My point is that if you can describe a situation under Mac OS where FLTK does not handle correctly a retina display, there's good hope something can be done to improve that. | |
|
#6 | cyantree 12:23 Feb 08, 2016 |
| sorry for my misunderstand.
Situation is: In osx with retina, test/device.cxx, click "go" with fl_image_surface->window, the result window is blur. Because fl_create_offscreen() and copy_offscreen() are not process retian display scale right. It should has nothing to do with Fl_Shared_Image::scale(). | |
|
#7 | manolo 23:37 Feb 08, 2016 |
| @cyantree: is this the usage scenario you would like to be improved: - create an Fl_Image_Surface object - draw into it - call Fl_Image_Surface::image() and get an Fl_RGB_Image object - draw the Fl_RGB_Image to the screen
If yes, I could try to improve this. What is needed is an object that contains two pieces of information: 1) its pixel size 2) its display size and that can have 1) twice as large as 2) to support retina displays. In FLTK, the Fl_Shared_Image class, together with its Fl_Shared_Image::scale() member function has these features.
Thus, the Fl_Image_Surface class could be extended as follows: 1) new constructor Fl_Image_Surface::Fl_Image_Surface(int w, int h, int highres) that would ask for creation of a high resolution drawing surface 2) new member function Fl_Shared_Image *Fl_Image_Surface::highres_image() that would return an image that has a display size and a pixel size twice as big, and that gets drawn at high resolution on the Mac OS X platform.
Please, let me know if that sort of new FLTK feature would solve your problem. Please, let me also know if that would not solve your problem. Thank you in advance. | |
|
#8 | cyantree 06:44 Feb 09, 2016 |
| I need fl_create_offscreen(), fl_delete_offscreen(), fl_begin_offscreen(), fl_end_offscreen() and fl_copy_offscreen() just for efficiency. If use Fl_RGB_Image, I'm afraid speed is slow a little.
Specific code is a little complex to Explain. web link: https://github.com/cyantreeguo/Fl_Scintilla/blob/master/fltk/PlatFLTK.cxx The point is void SurfaceFLTK::Init(Scintilla::WindowID wid); void SurfaceFLTK::InitPixMap(int width, int height, Scintilla::Surface *surface_, Scintilla::WindowID wid); void SurfaceFLTK::Copy(Scintilla::PRectangle rc, Scintilla::Point from, Scintilla::Surface &surfaceSource);
In short, the problem is fl_copy_offscreen() cannot process right with retina display. Not just osx, also win7 win8 win10. | |
|
#9 | manolo 12:02 Feb 09, 2016 |
| As I wrote before, I believe function fl_create_offscreen() and the other offscreen functions are not adequate to support high resolution because the offscreen object cannot contain two distinct sizes, the pixel size and the drawing size.
Why do you use these functions in the first place? At least on Mac OS X, when you draw to a retina display with the standard FLTK drawing functions, the system automatically detects the high resolution and adapts the resulting pixels accordingly. This also happens when text is drawn, and nothing special is required from the application to obtain this result. The device test application shows this clearly: move its window between a retina and a non-retina screen (an external display for example), and the system will automatically adjust the pixel resolution. That is specially visible with text. Apple's Pixel application helps seeing exactly how pixels are colored on the display.
To my knowledge, the only situations where high resolution support can be insufficient is when drawing images, (Fl_Shared_Image::scale() solves this problem), or when drawing to an offscreen pixel. For this second situation, I propose to extend the present API of the Fl_Image_Surface class (see my point #7 in this STR).
Let me know, please, if I am missing another situation where FLTK support for retina displays is insufficient. | |
|
#10 | manolo 12:05 Feb 09, 2016 |
| Correction: the name of the Apple app helping to see pixels is Pixie (not Pixel). | |
|
#11 | manolo 00:57 Feb 12, 2016 |
| The new constructor and member function for class Fl_Image_Surface have been committed to the svn FLTK repository, and will appear in FLTK 1.3.4 soon to be released.
Fl_Image_Surface::Fl_Image_Surface(int w, int h, int highres) with highres != 0 constructs a memory bitmap of size 2*w x 2*h
Fl_Shared_Image *Fl_Image_Surface::highres_image() returns an Fl_Shared_Image object with 2*w x 2*h pixel size and w x h drawing size.
This allows to draw to an offscreen buffer and then draw the buffer to a retina display and obtain a result that is essentially pixel-to-pixel identical with what is obtained when directly drawing to the display.
I also believe the use of the Fl_Image_Surface object should not be slower than calling fl_create_offscreen() and other offscreen-related functions, because the underlying system calls are exactly the same. The Fl_Image_Surface object merely allows to handle properly an offscreen buffer having a drawing size distinct from its pixel size. | |
|
#12 | AlbrechtS 04:59 Sep 01, 2016 |
| Comment #11 seems to be a solution for the underlying issue w/o the provided patch.
Can we close this STR? | |
|
#13 | manolo 07:28 Sep 01, 2016 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |