Remaining bugs are related to :
1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-)
2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail..... Uninfluent, anyways.
3) GetDIBits on a source DIB with BPP <= 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP <--> internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix.....
There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-)
Austin, could you please retest it against test suite ?
(code on Bug421 page)
Ciao
Max
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele:
- Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-)
Be careful with such statements. Look at bug 6519 for example.
Regards, Michael Karcher
Michael Karcher ha scritto:
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele:
- Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-)
Be careful with such statements. Look at bug 6519 for example.
Regards, Michael Karcher
Yep, I've seen the bug :-) Anyways, most failures are fixed by now, also for monochrome bitmaps. Did you test it on bug's 6519 app ?
Ciao
Max
Am Montag, den 18.05.2009, 13:41 +0200 schrieb Massimo Del Fedele:
Be careful with such statements. Look at bug 6519 for example.
Yep, I've seen the bug :-) Anyways, most failures are fixed by now, also for monochrome bitmaps. Did you test it on bug's 6519 app ?
No, I don't really care. I just fixed that bug and your statement: "Color on monochrome bitmap is seldomly used anyway" sounded an alarming bell in my head. This mail was just a warning to not disregard the issue and no specific problem report.
Regards, Michael Karcher
Massimo Del Fedele wrote:
There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-)
Hey Max,
It sounds like you're in a better position than most to write a conformance test for these missing/buggy features, since you're aware of them. That might help everyone, and also make your DIB engine more attractive since it'll be passing even more tests that current Wine may not be.
Keep up the good work :)
Thanks, Scott Ritchie
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele max@veneto.com wrote:
Austin, could you please retest it against test suite ?
I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time.
P.S., there's now a crash in user32/cursoricon.
Austin English ha scritto:
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele max@veneto.com wrote:
Austin, could you please retest it against test suite ?
I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time.
P.S., there's now a crash in user32/cursoricon.
Crash "fixed" on latest post. The fix is partial, as it depends on getting the right color table of a DIB from inside GetDIBits. That can't be done using GetDIBColorTable() as it requires the DIB to be selected into a DC, which is exactly the opposite requirement og GetDIBits. I guess I have to resort to a list of DIB <---> physical bitmaps to do it reliably, as windows doesn't bring any reliable other way to do it. Concluding : crash fixed but a couple of failures in tests/bitmap.c in addition to remaining 4. Total, 6, which is not bad :-)
Ciao
Max
Well, it seems that the engine fixes some unrelated bugs too :-) Bugs 15146 and 10408, as reported by a tester.
BTW In a couple of weeks all (few) remaining failing tests should be fixed. Then I'll try to optimize somehow the mixed blitting, which is the only stuff that remains slower than original.
Then, last but not least, I guess I'll setup a machine for weekly packaging for ubuntu.... many people are asking me for autocad usage.
Ciao
Max
On Wednesday 20 May 2009 00:13, Massimo Del Fedele wrote:
Well, it seems that the engine fixes some unrelated bugs too :-) Bugs 15146 and 10408, as reported by a tester.
BTW In a couple of weeks all (few) remaining failing tests should be fixed. Then I'll try to optimize somehow the mixed blitting, which is the only stuff that remains slower than original.
Then, last but not least, I guess I'll setup a machine for weekly packaging for ubuntu.... many people are asking me for autocad usage.
I've started testing your patches (btw, the 9th patch in your series is missing the 0009- prefix although the 'series' file claims it should have; also, it's a real pity that git am doesn't accept stgit patches 8-/ but anyway, that's off topic).
An application that you might want to test your DIB engine against is Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin has some subtle network bugs, and there is no Shockwave plugin at all, so it is still necessary for me to use Opera for Windows under Wine in a few cases.
Opera is a good test for your DIB engine because (1) it has problems with the current GDI32 stuff (2) it crashes with your DIB engine ;-)
There is currently a bug that makes the 'native' skin for Opera hard to use because many widgets fail to display properly (invisible or totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also the rendering of some Flash stuff is considerably buggy.
I was hoping to test Opera with your DIB engine to see if it works, and I came across this crash as soon as I tried rendering a webpage:
=>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=<register EDI not in topmost frame>, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=<register EDI not in topmost frame>, startscan=<register ESI not in topmost frame>, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=<register EDI not in topmost frame>, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) 7 0x7eb5255b LoadImageW+0x88b(hinst=0x67830000, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4)
I will try looking further into this, and provide any additional info I can find.
Giuseppe Bilotta ha scritto:
I've started testing your patches (btw, the 9th patch in your series is missing the 0009- prefix although the 'series' file claims it should have;
ops.... that was the hurry. stgit don't put the prefix, I added it manually just for who don't want to use it
also, it's a real pity that git am doesn't accept stgit
patches 8-/ but anyway, that's off topic).
well, never used git-am, but I feel quite comfortable with stgit... also because it make easy to correct or integrate a commit
An application that you might want to test your DIB engine against is Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin has some subtle network bugs, and there is no Shockwave plugin at all, so it is still necessary for me to use Opera for Windows under Wine in a few cases.
that's interesting.... I'll do it in short :-)
Opera is a good test for your DIB engine because (1) it has problems with the current GDI32 stuff (2) it crashes with your DIB engine ;-)
uhmmmmm.... see later, I'm afraid you didn't use the last posted engine...
There is currently a bug that makes the 'native' skin for Opera hard to use because many widgets fail to display properly (invisible or totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also the rendering of some Flash stuff is considerably buggy.
quite interesting and a good testfield. As I'm restructurating a bit the code to solve the last 2 non conformity on testsuite, I guess I'll check it shortly :-)
I was hoping to test Opera with your DIB engine to see if it works, and I came across this crash as soon as I tried rendering a webpage:
=>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=<register EDI not in topmost frame>, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=<register EDI not in topmost frame>, startscan=<register ESI not in topmost frame>, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=<register EDI not in topmost frame>, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) 7 0x7eb5255b LoadImageW+0x88b(hinst=0x67830000, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4)
That's the problem I'm solving with restructuration. In short, using GetDIBits and SetDIBits with a DIB bitmap instead a DDB (as I believed was the only usage for it....) I ran into problem of getting DIB color table. GetDIBColorTable() is useless because it needs the bimpap to be selected on a DC, which is the opposite requirement for Get/SetDIBits; I can't create a temporary DC from inside them because of the SysLevel error you ran into. I obviously can't also use GedDIBits to get the color table (!).... So I removed for the moment DIB handling from both function, and I'm coding the true solution, which is somehow complicated but almost done.
In short, if you're interested, the solution is to keep a linked list of HBITMAP <--> Physical bitmap for all DIBs, which allow accessing color table and other useful stuffs without resorting to GDI, which should be faster and less problem-prone. I'll post the code in few days. For then, I guess ALL non-conformities to test suite will be solved.
Ciao
Max
-
Austin English -
Giuseppe Bilotta -
Massimo Del Fedele -
Michael Karcher -
Michael Karcher -
Scott Ritchie