SetBufferedDraw(false) removes additional selection indication (and some other indicators) on OSX (Scintilla 3.2.3)

38 views
Skip to first unread message

Paul K

unread,
May 30, 2013, 3:00:21 PM5/30/13
to scintilla...@googlegroups.com
Neil:
 
I just noticed that I don't see any color on additional selections on OSX (Scintilla 3.2.3). On Windows the same code shows the same selection by default and when I adjust SetAdditionalSelAlpha I get a proper change in additional selection.
 
It turned out to be related to SetBufferedDraw(false) call I added on OSX to enable Retina support. When I set it to false, I see additional selection indication disappearing as well as some other indicators disappearing (for example, INDIC_ROUNDBOX); other indicators (PLAIN, DOTS, DASH) don't seem to be affected.
 
Is this a known issue? Is there a workaround?
 
Paul.

Neil Hodgson

unread,
May 30, 2013, 8:07:03 PM5/30/13
to scintilla...@googlegroups.com
Paul K:

I just noticed that I don't see any color on additional selections on OSX (Scintilla 3.2.3). On Windows the same code shows the same selection by default and when I adjust SetAdditionalSelAlpha I get a proper change in additional selection.

    The visibility of translucent features will depend on the display and platform used and the colour chosen. Setting selection.additional.back=#0000FF in SciTE shows additional selections as a light blue on my main MacBook display (a Dell 2005FPW) but its less intense on the built-in screen. Choose a colour and level of alpha that works for you.

It turned out to be related to SetBufferedDraw(false) call I added on OSX to enable Retina support.

   Buffered drawing is supposed to be permanently off on Cocoa since 2.28. Its initialised to false and the code responding to the call looks like this:
    case SCI_SETBUFFEREDDRAW:
      // Buffered drawing not supported on Cocoa
      bufferedDraw = false;
      break;

   Neil

Paul K

unread,
May 30, 2013, 8:28:38 PM5/30/13
to scintilla...@googlegroups.com, nyama...@me.com
Neil:
 
> The visibility of translucent features will depend on the display and platform used and the colour chosen. Setting selection.additional.back=#0000FF in SciTE shows additional selections as a light blue on my main MacBook display (a Dell 2005FPW) but its less intense on the built-in screen. Choose a colour and level of alpha that works for you.
 
Right; everything looks/works as expected as long as I don't call "SetBufferedDraw(false)".
 
> Buffered drawing is supposed to be permanently off on Cocoa since 2.28. Its initialised to false and the code responding to the call looks like this:
 
This is very strange. I can clearly call it with "SetBufferedDraw(true)" and indicators come back as they should be; I call "SetBufferedDraw(false)" and they disappear. I have a console in my application, so I can make these calls without restarting the app, so I can see the immediate effect.
 
Based on what you are saying, it shouldn't make any difference, right? This is all running on a *regular* MacBookPro (not Retina) with OSX 10.7.4. Any idea what may be going on?
 
Paul.

Neil Hodgson

unread,
May 30, 2013, 8:41:10 PM5/30/13
to scintilla...@googlegroups.com
Paul K:

> Based on what you are saying, it shouldn't make any difference, right? This is all running on a *regular* MacBookPro (not Retina) with OSX 10.7.4. Any idea what may be going on?

Looked through your posting history and it appears you are using wxStyledTextCtrl instead of the native implementation. wxWidgets may not have implementations for translucency or may differ in the way the alpha value is interpreted: possibly making it less visible.

Neil

Paul K

unread,
May 30, 2013, 11:38:36 PM5/30/13
to scintilla...@googlegroups.com, nyama...@me.com
Neil:
 
> Looked through your posting history and it appears you are using wxStyledTextCtrl instead of the native implementation. wxWidgets may not have implementations for translucency or may differ in the way the alpha value is interpreted: possibly making it less visible.
I indeed use wxSTC, but the interesting thing is that I can get the colors (including transparency) to work just find as long as I don't turn the buffering off.
 
I'm attaching three snapshots that show how it looks:
1. The first snapshot (-default) is taken when the app just starts. I disabled any explicit setting of BufferedDraw and
GetBufferedDraw reports "true", so it seems to be on. everything works/looks correctly.
 
2. The second snapshot is after I run SetBufferedDraw(false) (-false). Nothing is visibly changed, but if I move the cursor to those lines that have ROUNDBOX indicators, those indicators disappear. They don't reappear in any subsequent redrawing. As you can see, other indicators are still on and not affected.
 
3. The third snapshot is after I run SetBufferedDraw(true) (-true). Again, after the screen is refreshed, everything is back to normal.
 
Couple of other things. I don't see the fragment you references in the Scintilla version I have. It turned out to be 3.2.1 and the fragment that sets bufferedDraw looks like this:
 
 case SCI_SETBUFFEREDDRAW:
  bufferedDraw = wParam != 0;
  break;
This is in Editor.cxx; or do I look in the wrong place?
 
The other thing is that the text looks a bit crispier with BufferedDraw set to false, even though I'm using a regular (not Retina) screen.
 
In any case, -default and -true screenshots show that there is no issue with displaying indicators with alpha properties. And yet when BufferedDraw is false, all indicators that have any alpha property disappear (whether it's ROUNDBOX or AdditionalSelection). This doesn't seem to be wxwidgets/wxSTC specific issue (at least as far as I can tell). Thank you for looking into this.
 
Paul.
wxstc-setbufdraw-default.png
wxstc-setbufdraw-true.png
wxstc-setbufdraw-false.png

Paul K

unread,
May 31, 2013, 1:22:59 AM5/31/13
to scintilla...@googlegroups.com, nyama...@me.com
Neil:
 
I did find the fragment you referenced in cocoa/ScintillaCocoa.mm. There are only two places (and both set bufferedDraw to false). I don't have anything similar to that file in wxSTC, but I did set the default value to "false" as you have and recompiled the component to see if this makes any difference (I thought maybe the initialization order matters).
 
Unfortunately the result is the same: the default value is "false" now, but some of the indicators are still missing. Not sure what else to check.
 
Paul.

Neil Hodgson

unread,
May 31, 2013, 1:36:28 AM5/31/13
to scintilla...@googlegroups.com
This should be reported to the wxStyledTextCtrl maintainers.

Neil

Reply all
Reply to author
Forward
0 new messages