Opened 22 months ago

Closed 21 months ago

Last modified 21 months ago

#14757 closed defect (fixed)

wxScrolledWindow doesn't process EVT_PAINT events correctly

Reported by: JiveDadson Owned by:
Priority: normal Milestone:
Component: wxMSW Version: 2.9.4
Keywords: wxScrolledWindow MSW regression Cc:
Blocked By: Blocking:
Patch: no

Description

Obscure a scrolled panel with another window, and slowly drag the window away. The panel will not be painted correctly. There will be bands of background color showing. This defect was not present in v. 2.8.12. I seems to affect only scrolled windows. To reproduce, compile the "image" sample program with 2.9.4. Run it and drag another window over the image panel. The little Postit notes work well for that.

http://i.stack.imgur.com/f4fJn.png

Attachments (2)

paintdc_refactor_v2.patch download (10.0 KB) - added by ericj 21 months ago.
scrolledwindow_paintdc.patch download (4.5 KB) - added by ericj 21 months ago.

Download all attachments as: .zip

Change History (13)

comment:1 follow-up: Changed 22 months ago by vadz

  • Keywords regression added; WM_PAINT WM_NCPAINT removed
  • Summary changed from Stripes of background left on panel after paint-events v. 2.9.4 to wxScrolledWindow doesn't generate correct EVT_PAINT events

According to this message the problem is related to EVT_PAINT generation in wxScrolledWindow as it doesn't appear when directly overriding OnDraw().

comment:2 Changed 22 months ago by JiveDadson

  • Summary changed from wxScrolledWindow doesn't generate correct EVT_PAINT events to wxScrolledWindow doesn't process EVT_PAINT events correctly

comment:3 in reply to: ↑ 1 Changed 22 months ago by JiveDadson

Replying to vadz:

According to this message the problem is related to EVT_PAINT generation in wxScrolledWindow as it doesn't appear when directly overriding OnDraw().

Yes, we have had a long discussion about this on the mailing list. As of Oct 18, 2012 it is continuing.

Changed 21 months ago by ericj

Changed 21 months ago by ericj

comment:4 follow-up: Changed 21 months ago by ericj

Just putting my two patches here, so that they don't get lost.

scrolledwindow_paintdc.patch
This one removes the own paint event handler from wxScrolledWindow. As it was Connected() it was always executed before any paint event handler in user code. The default paint event handling (which will call wxScrolledWindow::OnDraw() will be called manually.

The m_hasDrawnWindow flag was removed.

paintdc_refactor_v2.patch
Refactors paint event handling. To ensure that BeginPaint/EndPaint is executed at most once for each WM_PAINT message, a hashtable with wxWindow* keys and wxPaintDCInfo* was introduced.

I've tested this patch with all drawing-related samples, all seemed to work fine.

Only exception: In the "controls" sample, on the first page, there is a small black rectangle in the upper left corner of the notebook page. It disappears when the window is minimized and restored again.

It's hard to tell if this is now a bug in the new code or if maybe it was a bug in the old sample code that's only visible now.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 21 months ago by JiveDadson

Eric, I want to test the patches. I tried applying them to the 2.9.4 code, but I got errors. Would it be possible to get an unofficial copy of the patched files? There are only a couple, right?

BTW, I discovered that the bug does not manifest itself when using (at least one of) the Aero themes under Windows 7.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 21 months ago by ericj

Replying to JiveDadson:

Eric, I want to test the patches. I tried applying them to the 2.9.4 code, but I got errors. Would it be possible to get an unofficial copy of the patched files? There are only a couple, right?

The patched files from SVN don't work unchanged in 2.9.4 because the changes of the new TextMeasure class also affect these files. If you don't want to get the files from SVN, you could try a daily snapshot from here: http://biolpc22.york.ac.uk/pub/Daily_HEAD/

BTW, I discovered that the bug does not manifest itself when using (at least one of) the Aero themes under Windows 7.

Yes, we noticed that, too. With the Aero theme the whole screen content is buffered for composition by the OS. This probably hides the problem.

comment:7 in reply to: ↑ 6 Changed 21 months ago by JiveDadson

Replying to ericj:

Replying to JiveDadson:

Eric, I want to test the patches. I tried applying them to the 2.9.4 code, but I got errors. Would it be possible to get an unofficial copy of the patched files? There are only a couple, right?

The patched files from SVN don't work unchanged in 2.9.4 because the changes of the new TextMeasure class also affect these files. If you don't want to get the files from SVN, you could try a daily snapshot from here: http://biolpc22.york.ac.uk/pub/Daily_HEAD/

BTW, I discovered that the bug does not manifest itself when using (at least one of) the Aero themes under Windows 7.

Yes, we noticed that, too. With the Aero theme the whole screen content is buffered for composition by the OS. This probably hides the problem.

I downloaded, built, compiled, and linked my program with the "daily head." The bug was still there. I tried applying the patches to the "daily head." I got the same error messages as before.

comment:8 Changed 21 months ago by vadz

Eric, thanks a lot once again. I'll apply both patches although I reworked the paint HDC fix one somewhat to avoid storing unrelated information inside the same wxPaintDCInfo class and to allow having only a single EndPaint() method.

comment:9 Changed 21 months ago by VZ

(In [72936]) Set ID correctly for wxScrollWinEvents generated by wxScrollHelper.

Add forgotten wxEvent::SetId() calls.

See #14757.

comment:10 Changed 21 months ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [72938]) Cache HDC used for painting for the entire duration of WM_PAINT processing.

This fixes a long standing problem with 2 wxPaintDC created one after another
(and not with nested lifetimes, which was handled by the caching mechanism
previously used) not working correctly. And as this was exactly what happened
when handling wxEVT_PAINT for wxScrolled, it also fixes drawing artefacts when
using scrolled windows.

Closes #14757.

comment:11 Changed 21 months ago by VZ

(In [72939]) Simplify wxEVT_PAINT handling in wxScrollHelperBase.

Just always call the virtual OnDraw() if wxEVT_PAINT wasn't handled. This is
much simpler than connecting our own special handler just to set a flag saying
whether the event was processed which was very complicated and didn't work
anyhow for the statically connected wxEVT_PAINT handlers.

See #14757.

Note: See TracTickets for help on using tickets.