[Libreoffice-bugs] [Bug 138122] LibreOffice text blurry on Retina displays on macOS 11

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=138122

--- Comment #118 from Tor Lillqvist <tml at iki.fi> ---
Interesting observation: Running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice --writer

will make the text you type into the Writer window show up crisp and nice.

But running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice /path/do/document.odt

does now change how it looks.

Very weird.

But note that even in the soffice --writer case, even if the text shows up
crisp, there are other problems, like the selection indicators don't show up at
all if you select part of the text you have entered. The
VCL_DOUBLEBUFFERING_ENABLE environment variable is related to an abandoned
effort to make VCL and the way LO uses it saner, or something. Here is a
discussion we just had on IRC (edited for clarity):

> tml__:   What does your comment "FIXME: this must disappear as we move to
>          RenderContext only" in vcl/source/window/paint.cxx mean?
> 
> vmiklos: It means that if application code (outside vcl) would store no state
>          during rendering (on the outputdevice), then such copying would not
>          be necessary. but today i guess we learned that app code won't be
>          changed that way (too much work).
> 
> tml__:   Idly wonders what RenderContext is.
> 
> vmiklos: RenderContext is just a typedef to OutputDevice; the idea was to not
>          paint at random times, but rather only paint when vcl gives you a
>          RenderContext. That's how practically all toolkits work.
>          But Skia, gtk3, Qt (and I would guess macOS, but haven't checked)
>          all gave up on changing non-vcl code, rather they maintain this
>          backbuffer (so non-vcl code can draw at random times) and just
>          copy the backbuffer to the final place when they get a drawing
>          context from the OS/underlying toolkit (on idle).
> 
> tml__:   I didn't even know that there had been such an attempt/wish/plan to
>          "move to RenderContext only".
> 
> vmiklos: https://speakerdeck.com/kendy/rendercontext-and-double-buffering it
>          was an effort 6 years ago. I think the hope was that this way one
>          more backbuffer can be avoided for (back then) OpenGL, and the result
>          was that, no, too much work, just do this for OpenGL (and now Skia)
>          the same way as gtk3 does. Like, if this would work, then each
>          backend would not need their own backbuffer. (But it does not work.)
> 
> tml__:   And is this RenderContext effort then the same as that which
>          introduced that VCL_DOUBLEBUFFERING_ENABLE etc? Or unrelated?
> 
> vmiklos: Same
> 
> mmeeks:  AFAIR we had some death-march to try to make it work everywhere properly; that failed in the end,
>          and we did something -much- simpler that didn't burn several engineers for weeks =)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210106/c186672a/attachment-0001.htm>