FLTK logo

STR #3278

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 cyantree
05:32 Jan 24, 2016
Fl_Double_window.cxx.patch
0k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.