User forums > Using Code::Blocks

Slow scrolling? [Ubuntu]

<< < (21/22) > >>

Jenna:
As stated here:

--- Quote ---Some platforms behave differently when redraw calls are made inside paints so may need to schedule a paint on idle. They also differ in the information they provide about the paint region so may require overriding PaintContains.
--- End quote ---
It might be needed to paint in OnIdle-function as my patch doese.

Refresh() just invalidates the whole DC and initiates a repaint in the next message loop (this means outside the actual paint-event).
I don't know which solution is the better one.

dmoore:

--- Quote from: jens on September 07, 2012, 03:32:28 pm ---I don't know which solution is the better one.

--- End quote ---

Either one will work and should have about the same performance, so I doubt it matters.

Is it worth filing a bug against wxScintilla?

I tried to get to the bottom of this one, but keep hitting a wall. I stepped through the code with the debugger. After paintAbandoned is triggered a new DoFullPaint gets called from DoPaint. As far as I can tell the Paint call in DoFullPaint does attempt to redraw every line as should happen, but it seems to get clipped. I try clearing the clip region of the DC before the paint call, but that doesn't seem to do anything. It's hard to debug, because the debugger will often hang (especially on linux).

dmoore:
So I guess that I have to give up and say that there is some platform limitation that prevents repaints outside the clip region in a paint handler. This affects both GTK and Windows. Not sure if it also affects Mac.

Reverting part of the 3.2.2 patch as follows would fix the problem:


--- Code: ---Index: src/sdk/wxscintilla/src/ScintillaWX.cpp
===================================================================
--- src/sdk/wxscintilla/src/ScintillaWX.cpp (revision 8358)
+++ src/sdk/wxscintilla/src/ScintillaWX.cpp (working copy)
@@ -911,7 +911,8 @@
     if (paintState == paintAbandoned) {
         // Painting area was insufficient to cover new styling or brace
         // highlight positions
-        FullPaintDC(dc);
+        FullPaint();
     }
     paintState = notPainting;
 }
@@ -919,8 +920,12 @@
 
 // Force the whole window to be repainted
 void ScintillaWX::FullPaint() {
-    wxClientDC dc(sci);
-    FullPaintDC(&dc);
+#ifndef __WXMAC__
+    sci->Refresh(false);
+#endif
+    sci->Update();
 }

--- End code ---

And at least on GTK seems to be free of nasty sideeffects such as generating duplicate SCN_UPDATEUI events.
  
However, something very similar to this FullPaint/FullpaintDC code appears in the native windows Scintilla port, so if it is broken here why isn't it also broken on the native windows version? The GTK version invalidates the window, and so effectively orders a full redraw. There's a recent change to the Mac version because I guess trying to repaint on the same DC didn't work there either:

i.e. Is attempting to re-paint during a paint a "platform limitation" that applies to all known platforms? :)

MortenMacFly:

--- Quote from: dmoore on September 08, 2012, 02:08:56 pm ---Reverting part of the 3.2.2 patch as follows would fix the problem:

--- End quote ---
If it works, feel free to commit, but please encapsulate it into /* C::B begin */, /* C::B end */ comments. In fact, I was indeed a bit curious about that change, because I also saw that in SciTE and ScintillaQT this is handled differently. Hence I thought "the wx guys should know" but it seems I was wrong. I didn't realise this bug until posted here... sorry.

Alpha:
I have tested this patch on Windows Vista and 7; it worked fine for me in those environments.

Navigation

[0] Message Index

[#] Next page

[*] Previous page