Author Topic: Chasing a paint bug  (Read 1725 times)

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Chasing a paint bug
« on: May 31, 2019, 06:17:21 PM »
I've been chasing a bug for some days now, and wonder if anybody has an idea what could be wrong.
It works most of the time, see attachment (no source yet, it's confused and huge). But sometimes I see that only a small 20x20 square in the upper left corner is being painted (correctly btw).
Size of the controls is OK, size of the two bitmaps involved is OK, too - checked with e.g.
Code: [Select]
invoke GetObject, APs.apBitmap, BITMAP, addr info
invoke GetObject, APs.apBitmap2, BITMAP, addr info
invoke GetClientRect, hCtrl, addr rc

GdiPlus calls do not report errors, Gdi calls are fine, too.
No significant leak (if any).
No heap corruption.
No crashes under the hood.
Sometimes the mouse cursor turns into a black square the same size as the painted little square.

The six controls have WS_THICKFRAME, sizing them has no effect. But when sizing the main window, it frequently starts working properly!

Has anybody seen something similar?

fearless

  • Member
  • ***
  • Posts: 458
    • LetTheLightIn
Re: Chasing a paint bug
« Reply #1 on: May 31, 2019, 06:34:17 PM »
Something to do with clipping or the z-order of the controls maybe?
Although just seen it now, moving around it showed part of a cursor and some other stuff. I would guess it might be related to a size of a bitmap or dc. Seen similar corruption when i have overlooked the size of the bitmap / dc being blitted - in effect had some extra space in memory that probably got filled with random stuff.
fearless

CM690II Case, HX1000 PSU, Asus Z97, Intel i7-4790K, Seidon 120v Cooler, 16GB DDR3, MSI GTX 980TI

My Github  Twitter

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Chasing a paint bug
« Reply #2 on: May 31, 2019, 06:50:48 PM »
Thanks, fearless. Yes, that is worth investigating.

In the meantime, I made some tests on my Win10 machine, and it gives me ValueOverflow for one call gdi+ call:
      invGdip GdipDrawLinesI, GraphObj, gdiPenOrBrush, edx, ecx   ; *graphics, *pen, *points, INT count

Checked twice, all is fine, if I reduce the count by one the last piece of the lines is missing :sad:

I'll keep you posted :smiley:

TimoVJL

  • Member
  • ***
  • Posts: 413
Re: Chasing a paint bug
« Reply #3 on: May 31, 2019, 06:57:05 PM »
After that program messes cursor, reset it to default from main.cpl -> Pointers -> Use default
or Control Panel -> All Control Panel Items -> Mouse -> Pointers -> Use default
May the source be with you

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Chasing a paint bug
« Reply #4 on: May 31, 2019, 08:15:31 PM »
Thanks, Timo. Yes indeed, the text selection cursor gets affected. I've checked the BitBlts using this code:
Code: [Select]
sub esp, BITMAP
mov esi, esp
invoke GetCurrentObject, BeginPtDC, OBJ_BITMAP
.if Zero?
fdeb 1, "Bad object", $Err$()
.else
invoke GetObject, APs.apBitmap, BITMAP, esi
fdeb 4, "bm1", [esi.BITMAP].bmWidth, APs.apRectL.right, [esi.BITMAP].bmHeight, APs.apRectL.bottom
mov eax, [esi.BITMAP].bmWidth
sub eax, APs.apRectL.right
.if Sign?
fdeb 1, "Gotcha A", eax
.endif
invoke GetObject, APs.apBitmap2, BITMAP, esi
fdeb 4, "bm2", [esi.BITMAP].bmWidth, [esi.BITMAP].bmHeight
mov eax, [esi.BITMAP].bmWidth
sub eax, APs.apRectL.right
.if Sign?
fdeb 1, "Gotcha B", eax
.endif
.endif
add esp, BITMAP
pop edi
pop esi
invnz BitBlt, BeginPtDC, 0, 0, APs.apRectL.right, APs.apRectL.bottom, PtDC, 0, 0, SRCCOPY

All fine, the bitmaps are big enough :rolleyes:

Tedd

  • Member
  • ***
  • Posts: 377
  • Procrastinor Extraordinaire
Re: Chasing a paint bug
« Reply #5 on: June 01, 2019, 10:56:07 PM »
The program doesn't render correctly for me on startup - just an icon-sized square in each panel's corner. Minimize-restore should cause a full repaint, but nothing appears to change.

Resizing the window provides some interesting clues: the 'icons' drawn in the corners appear to be bitmaps drawn from GDI memory; as the size of the window changes, the bitmap that is drawn walks through various system bitmaps/icons as if it were an image-list (they are drawn correctly and not at random offsets, so it's more likely they're indexed, or at least at some size-multiple offsets.)

Things to investigate:
  • Check that you are doing a full repaint (clear the background with a non-null brush.)
  • The corner-icon looks like some kind of corrupted index/offset value, so check all pushes & pops are balanced, also values in structures passed to drawing functions.
  • Build a 100% new version (no copy-pasting!), starting with the absolute minimum, adding parts until the problem appears (or doesn't, because it was a stupid typo somewhere.)
Potato2

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Chasing a paint bug
« Reply #6 on: June 01, 2019, 11:01:29 PM »
Thanks a lot, Tedd. I will keep you posted.

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Chasing a paint bug
« Reply #7 on: June 02, 2019, 05:53:01 AM »
Version 2 - one fat bug is fixed! Grateful for feedback on remaining problems.

TimoVJL

  • Member
  • ***
  • Posts: 413
Re: Chasing a paint bug
« Reply #8 on: June 02, 2019, 06:56:51 AM »
Now it works in old Windows 7 :thumbsup:
May the source be with you

Biterider

  • Member
  • ***
  • Posts: 375
  • ObjAsm32 + ObjAsm64 = ObjAsm
    • ObjAsm
Re: Chasing a paint bug
« Reply #9 on: June 02, 2019, 07:12:32 AM »
Hi JJ
Unfortunately Win10 sees your exe as infected by a trojan.  :undecided:
I got this when running


Biterider

fearless

  • Member
  • ***
  • Posts: 458
    • LetTheLightIn
Re: Chasing a paint bug
« Reply #10 on: June 02, 2019, 08:34:57 AM »
so what was the issue that was causing the paint bug?
fearless

CM690II Case, HX1000 PSU, Asus Z97, Intel i7-4790K, Seidon 120v Cooler, 16GB DDR3, MSI GTX 980TI

My Github  Twitter

LiaoMi

  • Member
  • ****
  • Posts: 573
Re: Chasing a paint bug
« Reply #11 on: June 02, 2019, 08:52:24 AM »
Hi jj2007,

I have an unusual behavior in the form of window teleportation  :azn:

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Chasing a paint bug
« Reply #12 on: June 02, 2019, 10:54:02 AM »
Thanks to everybody :smiley:

The 'fat' issue was a DeleteObject with a random argument: a local variable that should have been zero but was filled elsewhere with the width of the control. So DeleteObject, 300 (for example) deleted things owned by the system.

It works without crashes or duplicates now, see attachment - at least on Win7-64. On Win10 and on Win XP (!), some of the semi-transparent lines to not get painted; in addition, an invoke GetCurrentObject, DC, OBJ_BITMAP returns zero (on Win10 but not on Win7 or XP), but that seems not to affect the painting, so I guess (and it's no more than a guess right now) that Win7 has a default bitmap loaded while W10 and XP don't.

LiaoMi

  • Member
  • ****
  • Posts: 573
Re: Chasing a paint bug
« Reply #13 on: June 02, 2019, 03:01:37 PM »
I have other multiple artifacts, from unusual white squares to full lamination  :azn: the example is repeated every time you start, to see this, it is enough to switch the size of the internal windows, focus the mouse on the desktop, and re-activate the program window, continuing to resize the windows inside.

Does it make sense to use double buffering? During redrawing, I can observe quadratic flicker in the center of each of the inner windows.

Biterider

  • Member
  • ***
  • Posts: 375
  • ObjAsm32 + ObjAsm64 = ObjAsm
    • ObjAsm
Re: Chasing a paint bug
« Reply #14 on: June 02, 2019, 03:56:21 PM »
Hi
V3 seems to work on Win10 (64). I did not get the artifacts described by LiaoMi on my machine.

Biterider