I noticed that in the Regions screen F8 of the drawing sample the regions created using SetDeviceClippingRegion()
never update when they are scrolled out and than scrolled in to view.
I haven't investigated the issue in-depth, so I don't know what's going on here.
Before scrolling:
drawing.png (view on web)After scrolling:
drawing_bug.png (view on web)—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
To be honest, I never understood what was this demonstrating, so I'm going to have trouble fixing it. This code was originally added in bc3cedf ( Added test for region clipping. Corrected makefile., 2000-03-02) by @RobertRoeb but I doubt even he remembers what was this supposed to be about...
Maybe we should just remove this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I forgot to mention that the problem is only with the GDI
backend, not with GDI+
nor Direct2D
.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ugh, if there is difference between wxDC
and wxGC
behaviour, there is definitely a bug which needs to be debugged, thanks for mentioning this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
diff --git a/samples/drawing/drawing.cpp b/samples/drawing/drawing.cpp
index 532965c494..11d9c0c685 100644
--- a/samples/drawing/drawing.cpp
+++ b/samples/drawing/drawing.cpp
@@ -639,6 +639,8 @@ MyCanvas::MyCanvas(MyFrame *parent)
m_showBBox = false;
m_sizeDIP = wxSize(0, 0);
+ SetDoubleBuffered(true);
+
auto cursorBitmaps = wxBitmapBundle::FromBitmaps(wxBitmap(cursor_xpm),
wxBitmap(cursor_2x_xpm));
m_customCursor = wxCursorBundle(cursorBitmaps, wxPoint(4, 4));
The patch above fixes the problem for me. but then, there is still a difference between drawing backends:
1- With GDI+
and Direct2D
: All regions scroll with the canvas as you scroll it.
2- With GDI
: The grey regions don't scroll with the canvas.
and I don't know which behaviour is correct: 1 or 2 ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
To be honest, I never understood what was this demonstrating, so I'm going to have trouble fixing it. This code was originally added in bc3cedf ( Added test for region clipping. Corrected makefile., 2000-03-02) by @RobertRoeb but I doubt even he remembers what was this supposed to be about...
Maybe we should just remove this?
I added it in 2000 to discover subtle differences in region clipping code in 2025. I remember that very precisely.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
there is still a difference between drawing backends:
1- With
GDI+
andDirect2D
: All regions scroll with the canvas as you scroll it. 2- WithGDI
: The grey
regions don't scroll with the canvas.and I don't know which behaviour is correct: 1 or 2 ?
I think 2, but I will also check on wxGTK and wxMAC
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
1- With
GDI+
andDirect2D
: All regions scroll with the canvas as you scroll it.
That is wrong as clipping regions (and update regions) must not be scrolled, wxGTK and wxMAC behave like what you describe for GDI on wxMSW. The grey rectangles should get smaller at the bottom and eventually disappear, the smileys move up and also disappear eventually.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
there is still a difference between drawing backends:
1- WithGDI+
andDirect2D
: All regions scroll with the canvas as you scroll it. 2- WithGDI
: The grey
regions don't scroll with the canvas.
and I don't know which behaviour is correct: 1 or 2 ?I think 2, but I will also check on wxGTK and wxMAC
That's what I thought too.. i.e. grey regions shouldn't be scrolled.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I just tested wxGTK3
and wxQt
behaviours:
wxGTK3
& wxQt
) + wxDC
: is like GDI
.wxGTK3
& wxQt
) + wxGC
: is like GDI+
and Direct2D
.—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
So basically wxGC doesn't behave the same as wxDC but does behave the same in all platforms?
I'm not sure if we should change it in this case...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Does not wxOSX use wxGC to simulate a wxDC? But wxMac behaves correctly in the sample.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Does not wxOSX use wxGC to simulate a wxDC? But wxMac behaves correctly in the sample.
yes, wxOSX always uses wxGC for wxDC (dcgraph.cpp) since the move from QuickDraw to CoreGraphics somewhen in this century IIRC
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Does not wxOSX use wxGC to simulate a wxDC? But wxMac behaves correctly in the sample.
So wxGC implementation in wxOSX must have been done right from this point of view, but wxGC in the other ports is different...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Does not wxOSX use wxGC to simulate a wxDC? But wxMac behaves correctly in the sample.
So wxGC implementation in wxOSX must have been done right from this point of view, but wxGC in the other ports is different...
See #25877
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.