wxSTC loses indicators with alpha setting after disabling BufferedDraw (needed for Retina) on OSX

[paulc...@gmail.com]

Hi All,

 

While this may seem like an obscure case, but SetBufferedDraw(false) is needed to Retina displayes on OSX and it appears that this causes indicators that have alpha properties disappear from the screen. I thought it was a Scintilla issue, but based on the discussion with Neil, he suggested that it may be wxSTC-related (here is the discussion with screenshots: https://groups.google.com/d/msg/scintilla-interest/FVZEl7Qbydk/qxEyNYz4BdQJ).

 

The problem is easy to reproduce. create wxStyledTextCtrl, and do something like this:

 

editor:IndicatorSetStyle(0, wxstc.wxSTC_INDIC_ROUNDBOX)
editor:IndicatorSetForeground(0, wx.wxColour(128, 128, 255))
editor:IndicatorFillRange(0, 10)

 

it should apply the indicator to the first 11 characters in the editor. After setting editor:SetBufferedDraw(false), the indicator disappears and after setting it to "true", it reappears (you may need to move the cursor to refresh affected lines).

 

Any idea what may be going on and how to fix it? Thanks!

 

Paul.

[Vadim Zeitlin]

On Fri, 31 May 2013 12:20:56 -0700 (PDT) wrote:

> While this may seem like an obscure case, but SetBufferedDraw(false) is
> needed to Retina displayes on OSX

Interesting, why? If this really true, we presumably should be turning it
off ourselves in wxSTC.

> and it appears that this causes indicators that have alpha properties
> disappear from the screen. I thought it was a Scintilla issue, but based
> on the discussion with Neil, he suggested that it may be wxSTC-related

Unfortunately he didn't really say what could the problem be and I don't
know this code at all so the best way to debug this further would be to
compare what happens in wxSTC and in the native Cocoa implementation.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[paulc...@gmail.com]

Vadim:

 

>> While this may seem like an obscure case, but SetBufferedDraw(false) is
>> needed to Retina displayes on OSX

> Interesting, why? If this really true, we presumably should be turning it
> off ourselves in wxSTC.

This is per message from Neil: https://groups.google.com/d/msg/scintilla-interest/tj71w3UMj4s/aqdoz8lfbXIJ. I got a report from one of the users who confirmed the fix (I don't have Retina display to test myself and don't know how to check for it).

 

I'm not sure if we need to do it in wxSTC; can we detect that we are running on OSX with Retina?

 

> Unfortunately he didn't really say what could the problem be and I don't
> know this code at all so the best way to debug this further would be to
> compare what happens in wxSTC and in the native Cocoa implementation.

Me neither; I checked the Scintilla code, but there doesn't seem to be anything tricky in OSX-related files. I set it to false by default as he does, but it didn't change the outcome. Maybe someone with more faimilarity with OSX side can comment on this?

 

Paul.

 

[paulc...@gmail.com]

Vadim:

 

It turned out that it's possible to emulate HiDPI resolution on some non-retina displays as well, so I took a screenshot on a MacBookAir.

 

Here is the screenshot (attached) with SetBufferedDraw disabled. Fonts in wxSTC components are crisp, but the notebook tabs and buttons (x) are not. Is there anything that can be done to fix these?

 

Paul.

[Vadim Zeitlin]

On Tue, 11 Jun 2013 14:22:57 -0700 (PDT) wrote:

> It turned out that it's possible to emulate HiDPI resolution on some
> non-retina displays as well, so I took a screenshot on a MacBookAir.
>
> Here is the screenshot (attached) with SetBufferedDraw disabled. Fonts in
> wxSTC components are crisp, but the notebook tabs and buttons (x) are not.
> Is there anything that can be done to fix these?

Sorry, no, I don't know. But I'm quite confused because I don't see what
does this problem (which is real and should be fixed, probably by just
providing a higher resolution icon for NSImage to use) with
SetBufferedDraw() which only affects wxSTC?

[paulc...@gmail.com]

Vadim:

 

> Sorry, no, I don't know. But I'm quite confused because I don't see what
> does this problem (which is real and should be fixed, probably by just
> providing a higher resolution icon for NSImage to use) with
> SetBufferedDraw() which only affects wxSTC?

You are right; these are two different issues... Should I open tickets for these?

 

Paul.

[Vadim Zeitlin]

On Tue, 11 Jun 2013 16:09:24 -0700 (PDT) wrote:

> > Sorry, no, I don't know. But I'm quite confused because I don't see what
> > does this problem (which is real and should be fixed, probably by just
> > providing a higher resolution icon for NSImage to use) with
> > SetBufferedDraw() which only affects wxSTC?
> You are right; these are two different issues... Should I open tickets for
> these?

Yes, but please try to reproduce it using the minimal amount of code
possible, i.e. without using wxAUI unless the problem really only happens
when using it.

I suspect that the bitmap problem should be visible when doing a simple
wxDC::DrawBitmap() call. As for the text, I'm not sure...