Re: Status of DIB engine ?
Il 24/12/2011 08:59, Alexandre Julliard ha scritto: Massimo Del Fedelem...@veneto.com writes: So, the question : have I understood right from changelogs and text is completed in DIB engine, so I can help to make it a bit faster, or it's still missing something so I should just wait ? Text is done. Most likely Autocad is using some other call that still goes through X11. You should be able to see this in debug traces. Hi Alexander, that's weird, because when I developed the former engine, I solved the slowness just when I introduced text output. Anyways, I'll try to look at logs if I can find the problem. Max
Status of DIB engine ?
As I've got no idea of the status of DIB engine, besides looking at changelogs, I'd like to know it... at least to see if there's some need of help. The stuff that interests me at most is, as usual, the display speed of autocad with embedded truetype fonts (aka bug 13801), which depends deeply on DIB engine. From what I see in changelogs, text output seems to be completed; well, the speed of autocad text rendering has risen a *small* bit, but it's still unusable, light years far away from speed of my old engine which I'm still using for my job. So, the question : have I understood right from changelogs and text is completed in DIB engine, so I can help to make it a bit faster, or it's still missing something so I should just wait ? Max
Re: [rfc] WINE_ONCE macro
I introduced exactly the same on my old DIB engine, to avoid tons of FIXMES :-) I find it quite useful. Max
Re: Statur of DIB Engine
Il 25/07/2011 10:20, Huw Davies ha scritto: On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote: Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. This is a good summary of where we're at - nicely done Octavian. The next step is cross-device blitting, which is what Alexandre and I are working on at the moment. Huw. Indeed that one was the big problem of my engine, impossible to do efficently without support from underlying drivers (winex11). Is font support for DIBS foreseen in short time ? Max
Statur of DIB Engine
Having seen many patches related to DIB engine lately, I built latest sources and tried it No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ? Sorry for asking here but, besides of git commits I've seen no explanation about what's happening. Also some users of my old engine, which are blocked to an old wine version (it is no more applicable to git tree since some time, because of recent changes) would like to know what's going on. Ciao Max
Re: Statur of DIB Engine
Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Thank you for your answer waiting for better times, so :-) Max
Re: Statur of DIB Engine
Il 24/07/2011 19:32, James McKenzie ha scritto: On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James Hi James, I guess that would be almost impossible to rebase my code there... For the few I've seen, the approach taken by Huw is too different from mine to have both coexistent, and the infrastructure changes would make the porting quite complicated and, which is worse, too dependent on code base changes to be maintainable by me. The only stuff that could be done would be to submit patches to enhance current graphics primitives but I guess Huw has already something in mind, and I've got too few spare time :-) Again, for what (very few indeed) I've understood from patches titles, some low-level primitives were exported from winex11 - gdi32 drivers, a stuff that was told me impossible when I developed my engine and that will make easy to solve the biggest problem remaining on it, the mixed DIB-DDB conversions in an efficient way. So, I'll wait to see what happens to Huw engine. A pity because latest progress in wine solved many other problems unrelated to DIB. Autocad users can just hope that fonts primitives will be embedded soon :-) Ciao Max
Re: bricscad goes native
Il 24/05/2010 02:39, Dan Kegel ha scritto: I've long predicted that companies might use Wine for a while to ship Linux-compatible products, and later switch to a native build once they know they have users. Well, now we have at least one example of this: Bricscad (see http://www.bricsys.com ). This is a *good* thing, and validates somewhat the idea that Wine is a catalyst to enable a global shift from Windows to Linux. mh... I'm following bricscad development and I'd say that the winelib version was quite a flop too many problems and didn't have the expected success. The linux native version is (imho) a courageus effort of Bricsys team to give Linux something that was missing since too long time :-) Pity for the choice of wxwidgets, indeed it's becoming too old style, imho, and the portability level isn't that easy. Ciao Max
Re: [Bug 20505] After winetricks comctl32, wine does not work completely
wine-b...@winehq.org ha scritto: http://bugs.winehq.org/show_bug.cgi?id=20505 Vitaliy Margolen vita...@kievinfo.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Vitaliy Margolen vita...@kievinfo.com 2009-10-28 23:53:57 --- Closing invalid. This one happens here too, and it used to work before, so IMHO is a regression. Max
Re: [Bug 20505] After winetricks comctl32, wine does not work completely
James Mckenzie ha scritto: wine-b...@winehq.org ha scritto: http://bugs.winehq.org/show_bug.cgi?id=20505 Vitaliy Margolen vita...@kievinfo.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Vitaliy Margolen vita...@kievinfo.com 2009-10-28 23:53:57 --- Closing invalid. This one happens here too, and it used to work before, so IMHO is a regression. I beg to differ. The use of winetricks to get around shortcomings of Wine is not a Wine developer issue and should be addressed to Dan Kegel and Austin English. James McKenzie I agree with you that the use of winetricks and native dll is not a wine devel issue, but here things are different The DLL USED to work, and now it doesn't. BTW, it doesn't for some apps (winecfg in primis) and it do for others. So, I see it as a regression. Maybe there are good reasons because it doesn't work anymore, maybe it's a bug introduced in new versions which is worth to analyze. Max
Re: DIB engine
Ben Klein ha scritto: You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, Well, well there are some, indeed. Of course, it's better not add new ones :-) hence AJ's reluctance to include the current DIB proposal in Wine (to make it correct later will require a lot of hacking, as Max has objected). Again, my engine isn't a hack. Nor you'll need hacks to embed it on gdi32. Even more, some parts will be simplified because of direct access to internal gdi32 structures, which can't be done (without hacks) in current implementation. The *only* semi-hack is the direct access of gdifont struct from inside winedib it could also be avoided, but with much useless code added. Useless because it will be so once embedded in gdi32. Do we even have an architectural document or guidelines to reference? This was also raised on the existing thread. No. This is a problem. The best we have so far is DIB engine should be integrated into GDI32. This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source. You got exactly the point :-) To be precise, the effort isn't so huge, but summed with the effort of maintaining all in sync with current tree the global effort would be great (and dumb, imho). Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32. There's not too much to adapt moving the engine inside gdi32 is (IMHO) not complicated at all. More a writing effort than a coding one. But, *before*, I guess winex11.drv (and any possible driver that does DIBs internally) should be patched stripping DIB handling *and* adding some stuffs for mixed transfers. Again, not an huge work, for somebody that knows well drivers internals. It could also be done later, if wished... but logically that would be the first step. Ciao Max
Re: DIB Engine : passing all tests
HI Ben, Ben Klein ha scritto: Of course, it also makes it more difficult to maintain, with any change in gdi32 needing to be mirrored in the forked DIB engine, but that's where git cherry-picking can come in handy :) Done for about 3 monthes, no more time for it :-) What I was trying to say with my post was not to rehash old ideas, but to say here's where I feel you need to be going. AJ doesn't seem to like the intermediary driver which forwards non-DIB requests, so in order to get this into the upstream tree, what needs to be done is an integration with gdi32, as in replacing the DIB-related methods with the DIB-engine, instead of doing (what can be seen as a hack) redirection of selected methods. I believe that if the majority of the intermediary design (with the intermediary driver) has been implemented and is working, it's time to start thinking of integrating it into gdi32 so that it is suitable for upstream inclusion. IMHO, and really in my opinion, loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. Ciao Max
Re: DIB Engine : passing all tests
Dmitry Timoshkov ha scritto: Massimo Del Fedele m...@veneto.com wrote: The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a transient phase, at the end all dib processing should go inside gdi32. Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called GDI font (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new font driver, so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing. I begin to repeat stuffs too often lately. As I already wrote, *I know* and *I agree* that DIB should belong to GDI32. The proposed driver is a working step to that final goal. Point. Max
Re: DIB Engine : passing all tests
Ben Klein ha scritto: A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was good enough 25 years ago. I begin thinking to not be clear enough in what I write.. 2 Last words: 1) Huw's starting engine *was* a driver's one, and many people told it was the right way. Worse, it forked driver from inside gdi32, which was awful to maintain. 2) My engine insertrs itself between gdi32 and the display driver; I begins to be tired repeating that it's a step through the final design on where DIB are handled fully inside gdi32. The step is, imho, necessary to split DIB handling from DDB without having to rewrite at once half of gdi32 + half of winex11.drv and maybe others. It is *not* the final step, now it wants to be. It's made so to prepare the switching in a painless way, *if* accepted. If not, just prepare to have the sampe problems we had with mshtml switching on each gecko change. In my case that broke a lot of stuffs. We all know AJ wants things to be done the right way the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. again, I agree with that. Defining what is the right way is still a mysterious matter. Wine's patch acceptance policy specifically prohibits hack it until it works, which hack ? then worry about it later style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things. Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately. Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Last work about accepting or not hacks: I never proposed such patches. The most hacky stuff I sent (and was rejected, with a motivation that could be right) was the addition of page size handling inside wineps.drv. Motivation was that the printer driver shoul be rewritten for cups without lpr usage. I agree. But by now *is* using lpr and *is* lacking support for page size and other stuffs. So I asked myself : it's better to wait up we have the complete right code, leaving the printer driver missing stuffs, or for the moment extend it while waiting for the right one ? I would have chosen the second solution, but as usual is a matter of taste. Max
Re: DIB Engine : passing all tests
Alexandre Julliard ha scritto: Hi Alexandre, One of the main problems I see is that your design is based on the premise that there's only one graphics driver, the X11 driver. Well, I guess I expressed myself not completely corrected. My engine do load the winex11 exactly as gdi32 does. That means that in must not be winex11, it can be any driver that gdi32 would have loaded. The loading phase is like this : GDI32 -- load any driver and gets function pointers for DC and bitmap (ORIGINAL) GDI32 -- load winedib.drv -- load any driver (etcetera) (MY WAY) The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a transient phase, at the end all dib processing should go inside gdi32. That's clearly not the case, DIBs can be used with any driver (and with multiple drivers at the same time). This is also why you can't have the DIB driver decide on when to forward/not forward to the X11 driver, it should go in the other direction. I'm also very skeptical about mirroring DIBs with a DDB. Well, that was just a thought. I think that maintaining a mirrored DDB copy would slow down just a bit drawing operations but would speed up a lot blitting. But it's not a need. But even if you do this that should be a purely internal x11drv decision, the DIB engine shouldn't have any notion about this at all. This means you can't expose DIB-DDB conversion routines, DDBs are entirely up to the graphics driver. I was meaning exposing a stripped-extended version of GetDIBits and SetDIBits, allowing partial image transfers. Again, that's not a need, it will just avoid code duplication in gdi32 and winex11. That would allow gdi32 to read and write portions of DDB with a call to winex11. Like it is now, you need knowledge of different DIB formats both in winex11 AND in gdi32; having this function would allow to move the mixed blitting stuffs almost completely inside gdi32. That's also just a suggestion. In my engine I have a bunch of PutLinexxx and GetLinexxx that do conversion from any format do 32 bit RGBA and vice versa; the functions I spoke about are just extensions of them for handling DDB conversion to/from 32 bit RGBA, and should reside, of course, in winex11. I agree with you that the DDB caching of DIBs should be a winex11 stuff and totally transparent to gdi32. Thanx for answers Max
Re: DIB Engine : passing all tests
Alexandre Julliard ha scritto: The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff. Hi again :-) Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped. Latters were one testcase (which was meant preparing some gdiplus patches) which was rejected because too long and with meaningless comments and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because contains errors (possible, but which ?) and were a pain to review (h). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-) I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help ! Anyways, to finish, I'm coding for fun (ops, I guess I already said that) and I also have a job and a family that takes most of my time. If I don't see the possibility that my patches are accepted in a couple of tentatives, I tend to keep them on my maybe useful stuffs tree; otherwise if I see the possibility of having them published I can spend a bit more time on them. Of course a comment like a pain to review doesn't push me to work hard on it. Ciao Max
Re: DIB Engine : passing all tests
Steven Edwards ha scritto: On Sun, May 24, 2009 at 10:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: That's ugly. Did you attempt to type in something in the Document area? I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next. Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEngine_OS_X.png http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibEngine_OS_X.png Since this is not likely to get merged in anytime soon, lets move the rest of the OS X related discussions back to the bug when bugzilla decides to stop munching on the pesticide. I'll try to file more detailed reports as time permits. Max this is wonderful progress, please keep up the good work! Thanks He Steven, Thank you for testing and for your words :-) The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions. There is also a small stuff in AlphaBlend() with DDB as source, which is still not implemented, but should be trivial too. Another stuff that needs to be fixed is font handling; by now is not complete even if it's mostly functional: it does not kerning (you can see it easily on some apps, autocad too) and font sizes sometimes are wrong. All these stuffs should be trivial to fix, but I have really few time on these days, so it will take some time. Ciao Max
Re: DIB Engine : passing all tests
Alexandre Julliard ha scritto: Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far. Well, I still think that the goodness of a design is a matter of taste. My design is *a* design, started because of a personal need and evoluted by *my* personal taste, which was the only way I had without proper roadmap. Btw, I thought to have explained enough the reasons of the choosen design, but I may be wrong so I'll put again here the pursued goals : 1) Something usable. That means something that don't work just for a couple of apps but that work in general at least as current driver do. This goal il about 90% to be reached, imho. It'll be 100% in a couple of monthes, if my job will let me enough spare time. 2) Something optional. There's no point, imo, to make a driver that breaks even just one app without the ability to fall back to original gdi32/winex11. Goal 100% reached. 3) Provide a working engine that allow in deep testing of speed difference. We know that *some* apps do benefit of it (again, autocad speed gain on TT fonts is something like 50x - 100x), but I've seen that recent thoughts were those of a limited speed gain Well, I think that many important apps could benefit of it. Goal 80% reached, as mixed blitting is something slower than original driver. No simple way to make it as fast without touching winex11.drv. 4) prepare the road to a definitive migration to what I think should be the right final design, so DIBs handled by gdi32 double buffered by DDB inside winex11.drv; mixed blitting done inside winex11. I think that one would be the only viable way if we want blitting speed *and* DIB drawing speed. My driver is doing the needed separation of 2 processes. Once completed, moving them into gdi32/winex11.drv should be quite easy and could be done stepwise. 5) for fun. Ops, that one should be the n. 1 :-) About point 4, which, I guess, is the most important for you, the next step would be to make a winex11-2.drv on which DIB processing would be stripped away, and with added DDB buffering of DIBs and mixed blit operations. That driver could be connected to (and tested with) winedib.drv, always as an option in registry/environment. Once ready and stable enough it should be made permanently enabled and remaining part of winedib.drv could be merged inside gdi32; that could also be made stepwise. Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least if we don't want to change something in driver function tables which would be the best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor I think to do it for the moment). A simple GetLine() * PutLine() that do translation between 32 bit RGBA -- DDB inside winex11.drv and callable by gdi32 would of course avoid all code duplication needed for mixed blitting, keeping needed speed. That addition would be trivial. I think my design has some advantages and some disadvantages to other ones, but it's superior to the double pointer approach taken before, for reasons already explained. The main disadvantage, maybe the only one, is to have for some time 2 different drivers in wine. but OTOH it allows deep testing without breaking anything. I hope I explained enough about it. Technical details are in (maybe too abundants...) code comments. Ciao Max
Re: DIB Engine : passing all tests
Ben Klein ha scritto: 2009/5/24 Massimo Del Fedele m...@veneto.com: Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:palette.html Yep, I've seen it sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html too bad that the suite marks them as failures :-) Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed? I guess not, wine is not passing them, and it won't pass most of them without a proper DIB engine. Some of them are independent of dib engine, indeed, and could be fixed anyways. I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet? Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an alternative experimental driver in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever. Ciao Max
Re: DIB Engine : passing all tests
Kai Blin ha scritto: On Sunday 24 May 2009 06:54:10 Ben Klein wrote: Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed? They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine. Most but not all of them. A few of them could be fixed anyways. I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet? It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course. The problem here is that I've got no time to maintain an updated git tree with my engine and I'm still fixing stuffs, so I prefere to manage my patchset directly in order to avoid a 1000+ patches on my tree. Dumping my patchset on a git tree wouldn't make its usage easier and would make me loose time and bandwidth to maintain it. People able to check out a git tree and build it are also able to apply the patchset to a clean one. It makes them spare time, too, as they don't have to maintain and build 2 different trees. With stacked git it's easy to add/remove the patchset. Anyways, if somebody wont take the (again, useless imho) job of maintain an updated tree with it, feel free to do it :-) Ciao Max
Re: DIB Engine : passing all tests
André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes Max
Re: DIB Engine : passing all tests
André Hentschel ha scritto: Massimo Del Fedele schrieb: André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes Max would you provide your builds for us? Can do on next days. But I need some place on where to put the precompiled dlls... I guess nor bug421 page nor here are good places for it. Ciao Max
Re: DIB Engine : passing all tests
Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:palette.html Yep, I've seen it sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html too bad that the suite marks them as failures :-) Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/report.html (The user32 failure can be ignored, I get that spuriously without DIB engine). Thank you for report. I still have to do a couple of optimizations, some font cleanups and then it'll be finished. I guess I'll setup a build machine for debian/ubuntu packages shortly. Ciao Max
DIB Engine : passing all tests
I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Ciao Max
Re: DIB Engine - Mostly fixed against test suite
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 ;-) uhm 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=0x6783, 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
Re: DIB Engine - Mostly fixed against test suite
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
Re: DIB Engine - Mostly fixed against test suite
Austin English ha scritto: On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele m...@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
Re: DIB Engine - Mostly fixed against test suite
Michael Karcher ha scritto: Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: 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 :-) 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
DIB Engine - Mostly fixed against test suite
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
Re: DIB Engine - first set of fixings agains wine test suite
Zachary Goldberg ha scritto: On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele m...@veneto.com wrote: Giuseppe Bilotta ha scritto: On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs. Now the problem is that it fixed also most todo_wines on bitmap suite As usual, on bug 421 page for who wants to test it. I noticed that you patches are not created with git format-patch (and thus cannot be applied with git am). Which tool are you using to maintain them? Maybe you could set up a public git repository with your patches applied on top of official Wine. I use stacked git to maintaint my patches. Instructions are on bug 421 page, but I'll repeat them here : 1) Install stacked git if you don't already have it : sudo apt-get install stgit (or whathever your distro needs) 2) switch to a new branch (stgit operates on branches, not on origin) git checkout -b dibeng-max 3) init stacked git branch (needed only first time) stg init 4) import the patchset stg import -s /path/to/patchset/series 5) if you want to get rid of stgit data, just commit the patchset that's not needed if you want to continue using stgit to push/pop/rebase the patchset stg commit (this one will leave you with a standard git tree again) 6) run autoconf -- that's needed because 'configure' file is NOT included in my patchset, as it changes too much from git releases and it is usually quite big patch autoconf 7) build as usual ./configure make depend make 8) enable the engine before running apps export WINEDIB=ON *or* fiddle with registry, as explained on bug 421 page if you want it permanent Ciao Max Max, Would it be possible to please make a wiki page with all of this information? Theres something like 250 comments on bug 421 and its difficult to find the posts you refer to sometimes :) Thanks! -Zach Eh, sorry but I've got no time now But if some volunteer wants to do it for me is ok :-) Ciao Max
Re: DIB Engine : Almost 100% working
Joerg Mayer ha scritto: So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. Ah, wait it's not much better, is an alternative. As it is now, it gives speed improvement for some apps, and probably slowdowns for others. The slow downs are because of mixed bitmap blitting, which could be indeed solved. So, if your app does *many* dib drawing and few mixed blits, the speed can improve by high factors; the other way around it can decrease. It has also probably still bugs and for sure some primitives (rarely used) that are still not coded, as circle/ellipse/roundrect, for example. Those are trivial to add, but I still didn't need them To solve this problem from an end users view, I see two approaches: 1) Alexandre is willing to allow that code into the wine repository, so it can be maintained in sync with the existing wine code (it is my understanding that the modifications to existing code are quite small) and leave it to the user to choose which code to use. I'd agree with that one. adding an optional driver could do no harm, and would be enabled just on user request. The needed core code modifications are really really small, just few lines on a c file that (afaik) is not being modified since long time. It could even be done *without* any modification, but that would be much less comfortable for end-users, as they should fiddle with registry entries. 2) We use the same solution that is used by the linux kernel developers: Keep the official source clean but add any (dearly wanted/needed) features as part of the distribution kernel. That would mean maintain another repo in sync with the main one, not too hard job but I couldn't do it myself really no time. As I think that Alexandre has stated his preference (and I can understand him taking a long term view), I want to ask the packagers for the distros out there: Would it be OK for you to add the necessary patch into the code that you distribute. Personally, that means Marcus and the openSUSE wine packages :-) That one could be a nice solution, but I see it quite unlikely to happen. Usually packagers prefer the official stuffs. ciao Max
Re: DIB Engine : Almost 100% working
Henri Verbeet ha scritto: 2009/5/11 Joerg Mayer jma...@loplof.de: As I think that Alexandre has stated his preference (and I can understand him taking a long term view), I want to ask the packagers for the distros out there: Would it be OK for you to add the necessary patch into the code that you distribute. Personally, that means Marcus and the openSUSE wine packages :-) While distributions are of course free to do that, keep in mind that that would also make them responsible for supporting that code. I'm not sure how feasible that would be for something so close to core Wine functionality. As I told before, the engine almost doesn't touch wine core. It just add an intermediate layer between gdi32 and winex11.drv to handle DIBs. If not enabled, it can't simply harm anything, gdi32 will take the usual way through winex11. And, last but not least, the drivers *needs* to be explicitely enabled by end user if not, it's like it wouldn't exist. There's nothing to maintain in wine related do the engine, nor the way around. The engine as it is should be applicable to any future wine version, as lon as it doesn't change hardly the driver's function tables or driver loading in dlls/gdi32/driver.c, which is *very* unlikely to happen. Max
Re: DIB Engine : Almost 100% working
Austin English ha scritto: Perhaps a wine-experimental branch, with applicable warnings? Getting a bunch of people to test it may give us good data on how much it improves things, which is currently lacking. That one should be maintained too not a difficult task but a time consuming one. Still I think that the better way should be to include as an optional component in main tree. Max
Re: DIB Engine : Almost 100% working
Austin English ha scritto: On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele m...@veneto.com wrote: Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max FWIW, for those interested, I've added the DIB engine to my daily test runs. First result is here: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904-dibengine/report.html and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904/report.html (everything passes on my machine, aside from the known spurious test results). Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap (1317!), and gdi32:palette. So not quite ready yet (architecture designs aside). Ah, yep swapped colors in pixels. I fixed that everywhere but not on getpixel :-) I'll fix it later and I'll look to other (few) failures. I've seen some stuffs passed on todo, also. Max
Re: DIB Engine : Almost 100% working
Scott Ritchie ha scritto: As a packager, as long as Massimo is willing to keep the patches applying to the latest version and user-optional to enable, I'd be willing to bundle em. I'm normally averse to keeping deltas with Alexandre's main branch other than backports, but this one is specifically written to not do anything unless manually enabled. Well, the engine should apply to any next git, as long as there are no changes to driver's function tables (unlikely), to gdifont struct (less unlikely, but should not happen soon...) and to dlls/gdi32/driver.c (also unlikely, as it has just code to load drivers). That was one of the 2 reasons of the new approach... to not to have to rebase it manually each week :-) BTW, about the bugs spotted by testsuite, I'm looking at them just now, mostly are just GetPixel() swapped colors, I got rid of more than an half with a single patch and I guess they'll mostly disappear in short time. Ciao Max
Re: DIB Engine : Almost 100% working
Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max
Re: DIB Engine : Almost 100% working
Warren Dumortier ha scritto: 2009/5/10 Massimo Del Fedele m...@veneto.com: Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong? Well, I'm not a big game player, so I don't know how many games would benefit of it. I tested Age of Empires, menus with many texts are very fast now. Arx Fatalis works, but I didn't make comparaisons. On apps sides: Autocad works like a charm, tested on 2005 and 2008. MS Messenger 7.5 works I didn't test Emule because (IMHO, of course) it's a nonsense to use an app for which there's a perfect counterpart on Linux Ciao Max
Re: DIB Engine : Almost 100% working
James McKenzie ha scritto: Good work. Have you started to think about how to get this into Wine where AJ will approve? James McKenzie Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the trial and error way up to it's approved. The easiest way I see by now is to add it to wine drivers as an alternative driver in parallel to X11 one. That could be done in less then 5 minutes and with no regressions :-) As I said before, to include it as replacement of actual driver would mean to make an half rewrite of both gdi32 and winex11. BTW, my engine has still space for a 3 optimizations that could speed it up even a lot more : 1) Font caching - shouldn't be too difficult 2) Access DDB directly for blit - not too difficult, and could bring a speed gain of 100% on mixed DDB/DIB operations 3) xxxBlt are not very optimized I would expect another 50-100% speed gain on blitting with few codelines more. Ciao Max
Re: DIB Engine : Almost 100% working
Roderick Colenbrander ha scritto: Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it. Roderick I'm (and not just me, afaik) still very, very but really very curious to know *which* would be the correct design BTW, I made my design because I needed it, and I'm happy if it'll be useful for some other people, quite probable stuff having seen the amount of words wasted about the subject from year 2002. Anyways, if instead of having it as an alternative solution inside wine tree (which would make stuffs easier for people needing it, for example cad users) we want to let it hanging on bug 421's page hoping to have the right solution in a bit less than another 7 years, ok :-) Max
DIB Engine : Almost 100% working
Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max
Limit of todo_wine ?
Today writing a testcase I found a problem on todo_wine construct.
In short :
void first_test_part()
{
ok(test1(), failed\n);
}
void second_test_part()
{
ok(test2(), failed\n);
}
todo_wine
{
first_test_part();
second_test_part();
}
this fails (i.e. is marked as passing inside todo_wine block)
if first_test_part() passes, which is not what wished;
in this case the test should be considered passing if BOTH
first and second part passes, and failed otherwise.
The problem arose on bitmap creation test (gdiplus) on which
the testcase should check for creation success AND bitmap
internal consiscency.
My example is short, but in my case there's a single function used
to test many kind of bitmaps; that's impossible to do with
todo_wine actual construct.
It could be obviously separated into many functions, each enclosed
on its own todo_wine, but this would vanify the single test function
for many bitmaps types way.
Max
Re: Limit of todo_wine ?
Vincent Povirk ha scritto: This is by design. Each call to ok() is an individual test, independent of the others, and todo_wine marks them all as todo. If you have the same code running multiple tests, you can mark some of them as todo by putting a todo flag in your data. If you really want multiple checks to be dependent, you'll need to reduce them to one ok() call. Vincent Povirk Yep, that what I'm doing now but the code is quite less clean than before. Thank you for answer Max
Re: Giving up for now
Roderick Colenbrander ha scritto: Have you also tried to use the GDI AlphaBlend function? This is the one which should be used I think and we back it by XRender .. Roderick Sorry for the OT : apropos AlphaBlend and RGBA bitmaps... what happens with BitBlt on a destination DIB which has alpha channel ? it gets overwritten or the dest alpha channel is simply ignored ? I mean BitBlt(dstBmp..., SRC_COPY) what happens to dstBmp alpha ? and BitBlt(dstBmp..., SRC_AND) ??? Max
Re: Dib Engine: some update
Luke Benstead ha scritto: 2009/5/1 Scott Ritchie sc...@open-vote.org: Massimo Del Fedele wrote: I put on bug's 421 page an update of my dib engine. It implements AlphaBlend, StretchBlt and has many color fixes. If you want to try it, just follow instructions on above page. Ciao Max Keep at it, it's very exciting :) Thanks, Scott Ritchie Yeah, nice work Max! You are doing an amazing job, I just wish that we knew how to get it into vanilla Wine! My bro really needs this to move his (and several work) machines to Ubuntu, but unfortunately I'm 100 miles away and he wouldn't have a clue how to compile and patch Wine. I might have a stab at packaging a custom version :) Luke. Thank you all for your messages, I'm glad it's useful for somebody :-) I was thinking too on packaging a custom version with the patches on my tree btw, I have a couple more which weren't applied because ugly, one allows printing on formats different than printer's default one (a need for most autocad users...). I'm not too good on debian packaging, but if you have some script that can do it we could find a place to host them. Ciao Max
Re: Dib Engine: some update
Luke Benstead ha scritto: 2009/5/1 Massimo Del Fedele m...@veneto.com: Luke Benstead ha scritto: 2009/5/1 Scott Ritchie sc...@open-vote.org: Massimo Del Fedele wrote: I put on bug's 421 page an update of my dib engine. It implements AlphaBlend, StretchBlt and has many color fixes. If you want to try it, just follow instructions on above page. Ciao Max Keep at it, it's very exciting :) Thanks, Scott Ritchie Yeah, nice work Max! You are doing an amazing job, I just wish that we knew how to get it into vanilla Wine! My bro really needs this to move his (and several work) machines to Ubuntu, but unfortunately I'm 100 miles away and he wouldn't have a clue how to compile and patch Wine. I might have a stab at packaging a custom version :) Luke. Thank you all for your messages, I'm glad it's useful for somebody :-) I was thinking too on packaging a custom version with the patches on my tree btw, I have a couple more which weren't applied because ugly, one allows printing on formats different than printer's default one (a need for most autocad users...). I'm not too good on debian packaging, but if you have some script that can do it we could find a place to host them. Ciao Max I have a place we could host the packages, but it would take me some time to learn how to package Wine... I've only ever done small libraries. Scott, are you the Ubuntu maintainer? If so, do you have some script for building the packages? Luke. Well, I do have some script to package an app (Ultimate++), I could adapt them to package wine. Next days maybe. Max
Something wrong with those ?
http://www.winehq.org/pipermail/wine-patches/2009-April/072442.html http://www.winehq.org/pipermail/wine-patches/2009-April/072452.html Ciao Max
Re: The DIB engine... does anyone know how to get it into Wine?
Henri Verbeet ha scritto: I would of course expect Alexandre to be much more strict wrt. winex11.drv than wined3d since it's a much more critical component. of course :-) I'd also expect reputation / experience with winex11.drv and gdi32 to be taken into account. I.e., trust, if you like. I agree. That's why I've chosen the new approach. As a new driver it can't break anything, so it could (but I guess it won't) be introduced as an alternative display driver in parallel to winex11. Ciao Max
Re: gdiplus: Implement GdipCreateHBITMAPFromBitmap
Nikolay Sivov ha scritto:
Massimo Del Fedele wrote:
Massimo Del Fedele ha scritto:
Should work for both DIBs and DDBs format, but strange enough the
IPicture bitmap
inside wine gdiplus bitmap is always a 32 bit DDB by now... haven't
found any
other case.
Ciao
Max
sorry again... another dumb copy/paste :-(
Former had a spurious FIXME used for debugging purposes
Max
+IPicture_get_Handle(bitmap-image.picture, (OLE_HANDLE*)hbm);
+if(!hbm)
+/* FIXME: return appropriate error code */
+return GenericError;
+
+/* gets bitmap data and find out bitmap's type */
+if(!(size = GetObjectW(hbm, sizeof(DIBSECTION), ds)))
+{
+ERR(Couldn't get bitmap data\n);
+return GenericError;
+}
Could be HICON here (see GdipCreateBitmapFromHICON) or metafile.
Since there's no tests for that could you please an explicit FIXME for
that types?
Done, thank you for the hint :-)
Ciao
Max
Re: The DIB engine... does anyone know how to get it into Wine?
Hi all, I was thinking just yesterday to a temporary solution that could, maybe, be useful without disturbing wine main workflow. My new approach has the structure of an independent driver which, even if it uses winex11 for DDB processing, is seen as a completely separated driver by gdi32. By its structure it's also quite independent of wine main tree, in sense that he needs just a very small patch of gdi32, and could be made also working without this patch. So, my proposal : the engine could be added to wine tree as a new, alternative driver. Then people could choose if use winex11 OR winedib. That temporary solution could stand up to the right approach to integrate the engine into gdi32 is found. Ciao Max
Re: The DIB engine... does anyone know how to get it into Wine?
Jesse Allen ha scritto: On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele m...@veneto.com wrote: 2) when winedib.drv is working good enough, wanted to detach it from winex11.drv, so make another driver comprising DDB parts of wineX11 and all optimizations needed. This detaching thing is a little worrying. How will winex11 be called after detaching? . It simply won't be called. The replacement winex11 would contain the needed driver functionality. It's exactly the same as separating DIB from DDB from inside wineX11, but without the regression problems. The 2 winex11 drivers could remain as a stable and a development alternative. Once the replacement one is ready and tested, it would replace the old one. It's almost the same that happens with wine1.0 and the devel branch 1.1, with the difference that the new driver could be operated as an alternative to old one from the same build. Through winedib or gdi again? The first would not change functionality at all. The second is like the two driver method. It sounds like we ought to stick to the two separate drivers as a basis in development so we don't end up with something that can't be unglued easily. Well, now it *is* glued. That's just one way to unglue it. Ciao Max
Re: The DIB engine... does anyone know how to get it into Wine?
Roderick Colenbrander ha scritto: We shouldn't introduce a temporary driver. Why ? I can't speak for Alexandre but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32 Me too and I guess in a second step also move the conversion code over to gdi32 agree too and work with some capability flags which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code. perfect In a next step the DIB engine can be added. which next step ? then you'd already have the engine :-) Roderick Ciao Max
Re: The DIB engine... does anyone know how to get it into Wine?
Roderick Colenbrander ha scritto: No then you don't have the engine yet. In my proposal you would first make winex11.drv not depend on DIBs (the conversion code would still be in winex11.drv), uhmmm... and in the meanwhile where would be DIB processed ? then you move the conversion code over (you would still perform 8bit drawing using X by converting it to 24bit but this conversion would be done inside gdi32). That means taking a DIB, converting to a pixmap, send through x11, draw it, get it back from x11 and reconvert from inside gdi ? I guess you're replicating the bad behaviour of x11 driver just moving it to gdi32 and adding even more overhead In the third step you would add software based drawing functions, so the actual DIB engine. Roderick It wouldn't be simpler just start with DIB code, let X11 manage a pixmap copy of DIB, so replicating the drawings via software from inside gdi32 AND with X11 on the replicated copy inside it ? I guess that one should be the final result... Why all these intermediate steps which btw don't bring any advantage ? I still see the behaviour simpler : 1) Make DIB code draw to DIBS, forward to X11 the rest. From gdi32 or from winedib.drv it's just a matter of taste former would be definitive solution, latter would allow deep testing without breaking anything. To see the former way, just look at mshtml code and its associated regressions. 2) fork winex11.drv, putting inside all non-drawing and DDB stuffs from old winex11 and add brand new DIB-DDB cached pixmap handling 3) when 2 is ready, jsut replace old winex11 with new one; if you choose the first way on step 1 you're ready, if you've chosen the second way,migrate winedib.drv code into gdi32. No regressions, no hassles, progressive and clean. Max
Re: The DIB engine... does anyone know how to get it into Wine?
My personal final thoughts 1) It's obvious (but then, why we're repeating it forever ?) that final result is : DIB inside gdi32 and DDBs inside X11, with probably DIB cached to DDBs in x11 for performance reasons. 2) Assuming point 1, the *only* problem is to decide how get to it, so choose the best solution. 3) the best solution depends on zillions of personal factors. Here we say you can't have full wine bottle and drunken bride. So, can we afford months of regression bugs ? Perfect, just start adding/replacing code to gdi32 AND winex11.drv and it's all ok. But then I guess I'll stay with wine-1.1.20 forever, resorting to wine-1.1.5 when I need something that mshtml regressions broke... We can't afford that ? so there's no other way than fork display driver and let people who needs it to test the new one up it becomes stable enough to replace the old one. I guess we could speak about it for years, but I really don't see another path that the 2 above. And, btw, I still don't know which would be the preferred one. The rest are simple implementation details. Max
Re: The DIB engine... does anyone know how to get it into Wine?
Reece Dunn ha scritto: 2009/4/28 Massimo Del Fedele m...@veneto.com: My personal final thoughts 1) It's obvious (but then, why we're repeating it forever ?) that final result is : DIB inside gdi32 and DDBs inside X11, with probably DIB cached to DDBs in x11 for performance reasons. Agreed. 2) Assuming point 1, the *only* problem is to decide how get to it, so choose the best solution. There are probably other problems/issues/considerations, but that is the big one. 3) the best solution depends on zillions of personal factors. Here we say you can't have full wine bottle and drunken bride. I would say that there are a lot of factors (forget the personal part). Personal part is always there, we're not machines :-) So, can we afford months of regression bugs ? Perfect, just start adding/replacing code to gdi32 AND winex11.drv and it's all ok. But then I guess I'll stay with wine-1.1.20 forever, resorting to wine-1.1.5 when I need something that mshtml regressions broke... The rationale behind small incremental changes is that it makes it easier to bisect. If there is one big bang patch, and there are a hundred regressions, it is harder to identify where they are. Also, smaller patches make it easier to review and to verify correct. I agree, *when* it is possible. The question is. it is ? We can't afford that ? so there's no other way than fork display driver and let people who needs it to test the new one up it becomes stable enough to replace the old one. I guess we could speak about it for years, but I really don't see another path that the 2 above. And, btw, I still don't know which would be the preferred one. The rest are simple implementation details. The two things to get right are (1) the correct architecture and (2) an incremental migration strategy (i.e. a way to incrementally refactor the existing code to the new DIB engine/support code). Look at what is being done for the Direct3D 10 implementation, for example. I'd agree with you, if I'd see a way to do it incrementally without forking driver and without breaking the whole. I didn't look at Direct3d 10, but I guess he don't affect zillions of apps, does it ? DX10 -- Vista, and (AFAIK) most DX apps still use 9. Touching at gdi32 would break almost 100% of running apps if someting goes wrong. Another benefit to the small incremental, always functional approach is that the code will be tested by everyone who uses Wine and not just people who are testing the side-line patches. I'd agree again, *if* there is a way to do it incrementally. Sorry but I don't see any. You can't, for example, say ok, let's fix line drawings routines, from now they'll be done from gdi32, and don't touch the rest, because of the way DIB are tied to X11 pixmaps. For line routines, for example, you must, *at once* : 1) patch the gdi32 part, to draw directly on dib 2) patch the x11 part to avoid current convert-modify-draw-convert stuff that is done now and *just* for line routines, if you don't want to touch at rest. 3) all above should be done for each DIB format, so you have to multiply the stuff by 8 4) probably check the polyline and other drawing stuffs that may use parts of line drawing. Don't forget rectangle filling, pattern drawing. If you don't do 1+2+3+4 at once you'll have a regression. Even if you do you can, if something strange happens. Again, mshtml is a good example Nor can you take DIB away from X11 without patching the whole gdi32, or rewriting the whole X11 drv or both. There's no single routine in X11 that can be split/patched alone without affecting the whole, imho. Even just the 2 drivers approach meant an handful of sparse hacks on many gdi32 routines and it was a simple approach. The DIB engine is a huge undertaking. It is probably several years worth of effort to get right and requires a lot of knowledge to get right (both of Windows and Wine). Here I don't agree. My engine is far from being perfect nor complete, and I'm surely not a gdi nor an x11 guru. Not even a programmer... My job is civil ingeneering. Nor I'm an extraterrestrial :-) But it works good enough for many apps. It's just a collection of well known snippets and algorithms and the result of some days of googling for documentation. I just made it to have AutoCAD usable and it does, speeding it up often 100:1. I think it would require a couple of months to complete with enough testers, an another month to optimize a bit. One year or something more of my spare time. Once completed, the stripping/modifying of DIB code in X11 would be quite straightforward. Then, and only then, the engine could be embedded in small patches inside inside gdi32 just move the code from winedib.drv, routine by routine, making the winedib one just a forward call to the new X11 for the caching part. BTW, that's just my personal opinion, of course :-) Ciao Max
Re: Old regression in Autocad
The regression is completed by this one : -Second regression : Don't show second registration page and help contents 8d28f09d8a582ff499b5947a5a2d1cf2700fb259 is first bad commit commit 8d28f09d8a582ff499b5947a5a2d1cf2700fb259 Author: Jacek Caban ja...@codeweavers.com Date: Tue Dec 30 06:48:59 2008 +0100 mshtml: Wine Gecko 0.9.0 release. :04 04 40390dae8dde3dbef05e4f754437e7b8129703d9 a0ba652e905b5b7cf1e39566232dbcb9558e4993 M dlls This patch completed the regression and added a new problem : AutoCAD help content is no longer displayed. Now, I don't know if to open a couple of new bugs, just one or nothing. The first regression I spotted broke the first registration page, which worked anyways *only* with native shlwapi. The second one broke the whole autocad help system (which had indeed already some problems...) and also the second registration page, even if the first patch is withdrawn. Ciao Max
Dib Engine: some update
I put on bug's 421 page an update of my dib engine. It implements AlphaBlend, StretchBlt and has many color fixes. If you want to try it, just follow instructions on above page. Ciao Max
Re: riched20: fix placement of crlf on font table streamout
Austin English ha scritto: On Sat, Apr 25, 2009 at 12:56 PM, Massimo Del Fedele m...@veneto.com wrote: In riched20/writer.c the font table was erroneously streamed out with a \r\n after each font, instead of end of font table. Can be easily checked on rtf output from windows. AutoCAD 2005 was very picky with this, expecting an opened or closed bracked after each font, crashing if not found. Fixes Bug 14827 Can you add a testcase for this? Done, even if it was quite visible on windows RTF output. Ciao Max
Old regression in Autocad
Following patch c3bdda810243ed6c8d6b9960d1df3b534653b438 is first bad commit commit c3bdda810243ed6c8d6b9960d1df3b534653b438 Author: Jacek Caban ja...@codeweavers.com Date: Wed Sep 24 18:19:46 2008 +0200 mshtml: Use ActiveScript for JavaScript in file protocol documents. :04 04 61b72d076d5bcefd2ec1938442972f252d1ce7fc 7ce674ba65d818a7bbd8df8c6b4482fc024e1ebb M dlls Caused a regression on AutoCAD registration page display, which worked before with native shlwapi and now is broken even with it. Without native shlwapi for autocad 2005 and both shlwapi AND urlmon for Autocad 2008 it is broken anyways. Please look at bug 12570 for details, in particular at comment #44 for a simple test. Ciao Max
Re: richedit: Null terminate streamed out rich text.
Dylan Smith ha scritto: This can easily be tested by saving a rich text document in wordpad. The rich text will always be null terminated, unlike plain text files which will not have a terminating null byte. I noticed in a bug 14827 that AutoCAD 2005 looked for this NULL byte to determine the length of the rich text in its EditStreamCallback function given to EM_STREAMOUT, instead of using the cb parameter that provides the length. --- dlls/riched20/writer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) The patch is right (IMHO) but AutoCAD bug 14827 is still present, I guess it's another issue probably related to \fonttbl streaming out. Ciao Max
Re: Maybe already known stuff, but.....
Ben Klein ha scritto: Are there any cases like that where the sourcecode of the app is available? I see it much more useful to track the call stack inside wine, not in the app. In my app there's a crash that's triggered after many wine calls, and this was useful to track them down up to calling code inside the application. Of course you can do the same with debugger, IF the app is debuggable, or with +relay, IF the app hasn't some fancy copy protection that blocks it. That was my case. Ciao Max
Re: DIB Engine - New approach
Jesse Allen ha scritto: I'm trying to understand what the problem is to make you think there needs to be a change. Are most of the problems with Blt related functions? No It is my understanding the DIB engine should actually be able to call the display driver and vice-versa. So I think we shouldn't abandon the two driver approach, just add the capability to call each other. I believe GDI on windows has infrastructure for this too. As I said before, I firmly think that the DIB engine belongs to GDI and *not* to an external driver. That said, I was told that the right approach would have been : 1) a gradual introduction of the engine inside wine. 2) it shouldn't break anything on the way 3) it should be done in small patches I guess you've seen too, developing your engine, that all those requirement are impossible to meet at once. DIBs are by now too tightly integrated inside X11. The 2 driver approach was a compromise and, trying to use it, I have seen that it was cumbersome to maintain and very error prone. You have 2 DC function pointers, 2 DC physical devices and, the really bad stuff, the function pointers inside the bitmap structure that should be kept in sync with the DC ones. Even more, gdi code use bitmap function pointers to tell to which kind of DC belongs the bitmap. The SetOwnerDC() along needed to be patched because of that, and it wasn't enough, still. You can look at my previous code many, many small hacks here and there just to be sure that all pointers were kept in sync. The bitblt stuff was one of the easier part you can also see it in my new code, it's completely working now, beside the pattern blitting that need some more work. Then I thought all that stuff for what ? Just to have a compromise engine semi-embedded into gdi32 ? An engine that, to make it right would mean another almost full gdi and x11 rewrite ? An engine on which every small unrelated change in gdi32 could bring nasty bugs on the engine code ? And a stuff that had to be manually rebased on each change inside gdi32, hopelessly waiting to see it embedded in wine main tree ? No, thanx. The right way to do it would be, in my humble opinion, to fork X11 and gdi32 parts and to rewrite them moving all dib processing from x11 to gdi32, besides keeping, maybe, a pixmap copy of dib inside X11. But even being (maybe) able to do it, I guess that almost nobody would take the job without being sure that it will enter into main three some day at least, not me :-) So, mostly because I *need* the engine for my job, and because I was tired of manual rebasing stuff, and, last but not least, because I think it's the only viable way to prepare the stuff for the right migration of DIB inside gdi, I rewrote it with new approach. Advantages : 1) Almost no changes, by now, to gdi32 code nor to X11 code. The almost could also be none at all, if wished. Just insert winedib.drv on registry driver's names and the job is done. I did put the small drive load patch on gdi32 because I wanted it working without fiddling with the registry, and it's about 5 patched lines and a some 30 lines added. No more no less. No more hassles to maintain it on each git release. 2) It can't, by design, break anything. If disabled, it's just as it wouldn't exist. 3) Once setup and tested, it can be a good starting point to do the right approach, so to move DIB X11 code inside gdi32. When you have all DIB code inside winedib.drv, you could then, really step-by-step add some X11 optimizations and then move DIB code inside gdi32. When finished, the temporary winedib.drv would simply disappear. I can tell you, it took me more than 2 months to make it almost working with the 2 driver approach, and a whole couple of days (!!!) to make it *fully* working with the new approach and much more stable. Ciao Max
Maybe already known stuff, but.....
Today I found this :
#include execinfo.h
void BT(void)
{
void *array[50];
size_t size;
char **strings;
size_t i;
size = backtrace (array, 50);
strings = backtrace_symbols (array, size);
printf (Obtained %zd stack frames.\n, size);
for (i = 0; i size; i++)
printf (%s\n, strings[i]);
free (strings);
}
That allow to dump a backtrace (here max 50 frames) from inside a running
program.
Quite useful if app is non debuggable and don't run with +relay on because
of copy protection.
Ciao
Max
Re: DIB Engine - New approach
Jesse Allen ha scritto: What about other drivers? Is the DIB driver going to know how to handle the others then? The engine act as a filter between gdi32 and the DISPLAY driver, other stuffs are untouched. The changes on gdi32 are just to prefere the loading of the engine instead of normal display driver, IF the engine is available and IF it's enabled in registry/environment. When loaded, the engine resumes normal display driver loading, as was done previously in gdi32. Identical stuff, defaulting to wineX11.drv if not changed by registry key. The engine then forwards to X11 (or any other display driver) all calls related to DDB, and process directly the DIBS. He don't need to now anything about which display driver is loaded or it's internals... it just makes call to him as gdi32 do. This approach has 2 big advantages : 1) you don't have to fiddle with bitmap and dc function pointers inside gdi32, which revealed itself a very complicated and error prone stuff. Now gdi32 is unchanged. 2) having DIB engine acting as a display driver, it can be extended step by step to handle DDB too, if whished. Or, it can be made to handle only DIBs which format differs from X11 display's one, which are the true speed problem. Does it even make sense to keep the DIB engine a driver anymore? The alternative is, as usual, to rewrite a big part of gdi32 and x11 driver, and this can't be done step by step. The fact that X11 keeps a DDB copy of DIB inside it makes it almost impossible. Jesse Ciao Max
DIB Engine - New approach (resent as first got lost...)
The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and the other for normal display driver. This way had the disadvantage of having to keep in sync the DC with the right driver depending on selected bitmap, which lead to many small changes spread along all gdi code; going deeper with development this approach showed many limits and problems. So I decided to start again from scratch with a completely different approach which is giving good results and is quite less invasive on gdi32 code. Instead of doing : -- DIB ENGINE / GDI32 --- \ -- X11 DRIVER I took this approach : GDI32 -- DIB ENGINE -- X11 DRIVER The (X11) display driver is loaded from inside the engine, which replaces it from gdi32 point of view. The changes in gdi32 are *very* limited, just in driver.c code, making it to load (if desired) the engine instead of normal x11 driver. No other changes needed. I added as usual the code allowing to enable/disable the engine on request by registry and/or environment variable. If the engine is not present or disabled, the driver loader falls back to usual behaviour. The Engine then loads the X11 driver in init phase and acts as a gate depending on selected BMP, forwarding to X11 driver all requests for DDB bitmaps and doing the job itself for DIB ones. This approach showed many advantages, and I' almost ready converting all old code to it. By now I'm posting here 3 patches (EDIT : posted on bug421 page, as here they disappeared) showing the approach; the posted driver is a simple pass-throu one, so it just forwards all calls to X11 driver. The last patch of the series shows the forking behaviour of DIB/DDB processing from inside the engine, but still forwarding all to X11. I'd like some comments on the approach taken; on next days I'll post a more complete code with most of the engine implemented. Ciao Max
Re: DIB Engine - New approach (resent as first got lost...)
Reece Dunn ha scritto: 2009/4/14 Massimo Del Fedele m...@veneto.com: The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and the other for normal display driver. This way had the disadvantage of having to keep in sync the DC with the right driver depending on selected bitmap, which lead to many small changes spread along all gdi code; going deeper with development this approach showed many limits and problems. So I decided to start again from scratch with a completely different approach which is giving good results and is quite less invasive on gdi32 code. Instead of doing : -- DIB ENGINE / GDI32 --- \ -- X11 DRIVER I took this approach : GDI32 -- DIB ENGINE -- X11 DRIVER This looks interesting. Have you run it past Alexandre on IRC, as he's the one that you need to convince? - Reece I still couldn't speak to him next days, maybe. BTW, on bug421 page there's now a working engine with the new approach. Porting of all functionality of previous engine is completed. Patches should be now quite independent of wine release, as the changes to core code are really minimal. Ciao Max
Re: winex11.drv: SetDIBits fails when startscan != 0
Alexandre Julliard ha scritto: - descr.bits = bits; + descr.bits = (BYTE *)bits + widthBytes * (tmpheight 0 ? (height - startscan - lines) : startscan); You shouldn't need to change the bits address. After a deeper look at it, I think there's no other (simple) way to do it. Using ySrc parameter and changing the behaviour inside X11DRV_DIB_SetImageBits() will work for SetDIBits() BUT will break SetDIBitsToDevice() on which ySrc has a completely different meaning, as: - in SetDIBits, ySrc is not needed and it should be 0; startscan and lines specify the start line and number of lines to copy from dib - in SetDIBitsToDevice ySrc IS needed and represent the start line of DIB that must be transfered, and startscan and lines are useful just for banding the transfer in repeating calls. So, as both use X11DRV_SetImageBits(), we can't fix one without breaking the other if we do using ySrc and working from inside X11DRV_DIB_SetImageBits(). A cleaner way would mean extend the X11DRV_DIB_IMAGEBITS_DESCR descriptor adding startscan and scanlines parameters, and fiddle with about ALL X11DRV_DIB_SetImageBits_xxx functions and others not worth the effort, IMHO. Ciao Max
Re: winex11.drv: SetDIBits fails when startscan != 0
Alexandre Julliard ha scritto: Massimo Del Fedele m...@veneto.com writes: - descr.bits = bits; + descr.bits = (BYTE *)bits + widthBytes * (tmpheight 0 ? (height - startscan - lines) : startscan); You shouldn't need to change the bits address. Well, original code was descr.bits = bits; descr.image = NULL; descr.palentry = NULL; descr.infoWidth = width; descr.lines = tmpheight = 0 ? lines : -lines; descr.depth = physBitmap-pixmap_depth; descr.drawable = physBitmap-pixmap; descr.gc= BITMAP_GC(physBitmap); descr.xSrc = 0; descr.ySrc = 0; descr.xDest = 0; descr.yDest = height - startscan - lines; -- HERE descr.width = ds.dsBm.bmWidth; descr.height= lines; So, wrongly setting DESTINATION bitmap range, instead of SOURCE, which is the correct behaviour for SetDIBits(). I tried this one : descr.xSrc = 0; descr.ySrc = height - startscan - lines; -- HERE descr.xDest = 0; descr.yDest = 0; But it didn't work either, so, or I didn't understand how X11DRV_DIB_SetImageBits( descr ) works, or it has some bug. Looking more in depth inside X11DRV_DIB_SetImageBits(); it shows, for example : NO FIXING OF bits BEFORE case 1: X11DRV_DIB_SetImageBits_1( descr-lines, descr-bits, descr-infoWidth, descr-width, descr-xSrc, (int *)(descr-colorMap), bmpImage, descr-dibpitch ); So, X11DRV_DIB_SetImageBits() and X11DRV_DIB_SetImageBits_XXX() don't set correctly the starting of DIB image when transfering. I could do bits += height - startscan - lines; inside X11DRV_DIB_SetImageBits() instead of X11DRV_SetDIBits(), but somewhere it must be done. Please tell me how you prefere it's done. Ciao Max
Re: winex11.drv: SetDIBits fails when startscan != 0
Massimo Del Fedele ha scritto: p.s.: of course, it needs also widthBytes * (.) I just shorted it to show the problem :-) Ciao Max
Re: gdi32/path.c -- Allow PATH_ExtTextOut() handle nonprintablecharacters
Alexandre Julliard ha scritto:
GDI_ERROR is clearly not a valid buffer size, and must be checked
for. Please write test cases like Dmitry suggested.
Yep, right, GDI_ERROR is -1L, too large to be a buffer size.
Uhmmm... the only non-graphical testcase that occours to me is one
showing that GetGlyphOutline() returns NULL buffer size on non-printable
characters It does, both on wine and on windows, is the check inside
PATH_ExtTextOut() which is wrong.
It's done as
dwSize = GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_NATIVE,
gm, 0, NULL, identity);
if (!dwSize) return FALSE; --- ERROR ON SPACE CHARACTER
which should be
dwSize = GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX |
GGO_NATIVE, gm, 0, NULL, identity);
if (dwSize == GDI_ERROR) return FALSE;
But then, I'm still not sure IF GetGlyphOutlineW does return GDI_ERROR
when called with GGO_GLYPH_INDEX flag (msn is not clear about...) nor I
know how to make a call to GetGlyphOutlineW() requesting a buffer size
which simulates an error. I could do with a wrong HDC, but we will be
never sure that some other kind of error wouldn't return NULL instead of
GDI_ERROR. My patch simply avoided the problem with :
dwSize = GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_NATIVE,
gm, 0, NULL, identity);
if(dwSize)
{
HERE NORMAL PROCESSING - BUF SIZE OK
}
/* GetGlyphOutlineW may return null size for space character,
so we try to get the metrics for it */
else if(GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_METRICS,
gm, 0, NULL, identity) == GDI_ERROR)
return FALSE;
This is guaranteed to work as by MSN description.
Ciao
Max
Re: gdi32/path.c -- Allow PATH_ExtTextOut() handle nonprintablecharacters
Massimo Del Fedele ha scritto:
But then, I'm still not sure IF GetGlyphOutlineW does return GDI_ERROR
when called with GGO_GLYPH_INDEX flag (msn is not clear about...) nor I
know how to make a call to GetGlyphOutlineW() requesting a buffer size
which simulates an error. I could do with a wrong HDC, but we will be
never sure that some other kind of error wouldn't return NULL instead of
GDI_ERROR. My patch simply avoided the problem with :
dwSize = GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_NATIVE,
gm, 0, NULL, identity);
if(dwSize)
{
HERE NORMAL PROCESSING - BUF SIZE OK
}
/* GetGlyphOutlineW may return null size for space character,
so we try to get the metrics for it */
else if(GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_METRICS,
gm, 0, NULL, identity) == GDI_ERROR)
return FALSE;
This is guaranteed to work as by MSN description.
Ciao
Max
Hm... even better :
if(dwSize == GDI_ERROR)
return FALSE;
if(dwSize)
{
HERE NORMAL PROCESSING - BUF SIZE OK
}
/* GetGlyphOutlineW may return null size for space character,
so we try to get the metrics for it */
else if(GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_METRICS,
gm, 0, NULL, identity) == GDI_ERROR)
return FALSE;
This will work on evey possible case
Max
Re: gdi32/path.c -- Allow PATH_ExtTextOut() handle nonprintablecharacters
Dmitry Timoshkov ha scritto:
Massimo Del Fedele m...@veneto.com wrote:
This patch doesn't match the normal logic of ExtTextOut implemented
in dlls/winex11.drv/xrender.c, also this requires a test case for
both code paths.
Why ? As is it now PATH_ExtTextOut() simply returns FALSE on first
space or non-printable glyph, you can see easily printing something like
THIS IS A TEST on an open path.
BTW, this behaviour (GetGlyphOutlineW returning NULL on spaces) is
quite well known, and is NOT an error value, simply there's no glyph
outline for non-printable characters, so the requested buffer size is
NULL; the function just outputs the metrics.
You need to make PATH_ExtTextOut() behave like dlls/winex11.drv/xrender.c,
X11DRV_XRender_ExtTextOut() does, i.e. treat GDI_ERROR as an error case,
not 0.
I do :
dwSize = GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_NATIVE,
gm, 0, NULL, identity);
if(dwSize)
{
/* get and process glyph data */
}
else if(GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_METRICS,
gm, 0, NULL, identity) == GDI_ERROR) == HERE !
return FALSE;
The check against GDI_ERROR was indeed missing on original code, which
just checked for 0 result when asking for buffer size, returning FALSE
if found.
It could be done the way around, first getting the metrics and then if
no error the buffer size and the glyph data, but you'd have an
unnecessary added call to GetGlyphOutlineW() for printable chars.
Also, I don't know how to make a testcase with no graphic output
If you have some suggestion about, I can make one.
GetGlyphOutlineW doesn't produce any graphic output.
Yep, of course, but we don't need to check for GetGlyphOutlineW()
correctness (well, not for this case, at least). It IS correct.
If you ask for buffer size (as done on first call) it returns 0 on error
AND on unprintable glyphs. The GDI_ERROR value is returned ONLY when
asking just for metrics or trying to get the glyph data, NOT when asking
for buffer size (on which GDI_ERROR could be a valid buffer size), as
well documented on MSDN :
http://msdn.microsoft.com/en-us/library/dd144891(VS.85).aspx
(see return value)
The only test case I can see here is a graphic one, showing the missing
text after the space char on wine.
Ciao
Max
Re: gdi32/path.c -- Allow PATH_ExtTextOut() handle non printablecharacters
Dmitry Timoshkov ha scritto: Massimo Del Fedele m...@veneto.com wrote: PATH_ExtTextOut() uses GetGlyphOutlineW() which can return a NULL buffer size not just on errors but also on non-printable glyphs. Instead of aborting the function should check for such cases, get the metrics and continue. This patch doesn't match the normal logic of ExtTextOut implemented in dlls/winex11.drv/xrender.c, also this requires a test case for both code paths. Why ? As is it now PATH_ExtTextOut() simply returns FALSE on first space or non-printable glyph, you can see easily printing something like THIS IS A TEST on an open path. BTW, this behaviour (GetGlyphOutlineW returning NULL on spaces) is quite well known, and is NOT an error value, simply there's no glyph outline for non-printable characters, so the requested buffer size is NULL; the function just outputs the metrics. Also, I don't know how to make a testcase with no graphic output If you have some suggestion about, I can make one. Ciao Max
Some news about my DIB Engine.....
I've gone a bit further with my DIB Engine, mostly on gdi32 side, in order to solve the last problems, at least as seen in my favorite app, Autocad 2005. Previous version had a bug related to the *only* .net part of that app (which was obviously written by a 5 years old child, imho), the layer manager. On this one, a bitblt operation is done reading some screen part into a DIB when painting the dialog on screen. Worse than that, there are *many* small bitblt ops (like 40x1 pixels) on *large* source/destination bitmaps (like some hundred kB - MB of pixel data. Well, that stuff showed to me the big limit of the approach taken, the mixed driver one with different driver pointers on same DC. That's the approach taken by earlier intents of Jesse Allen and Huw Davies. So I decided to make a break, examining the problems so far and maybe discussing a bit about it. 1) Maintain DCs and bitmaps in sync with correct driver. That problem is fully solved, requiring some small hacks on many parts of gdi32, in detail in bitmap.c, dib.c and dc.c. Well, not really hacks, even if the code isn't as clean as I'd like. Difficulty here was mostly due to bmp funcs that should be identical to DC on which it's selected, on DIB creation and on BITMAP_SetOwnerDC() part. In short, that part should be quite good by now. 2) Now the big (and slow) problem : the mixed operations, those which uses both DIBs and DDB; BitBlt(), StretchBlt and so on. On those we can't simply use one driver because it can't handle other driver's bitmap. Well, X11 driver could do it, in theory, but having the DIB created by DIB engine makes it impossible (missing X11 physDev and related pixmap). So the problem, as correctly pointed by Jesse Allen, is to uniformize the DCs *before* the BlitBlt operation, *or* to make DIB engine able to deal with DDB stuffs. I discarded latter approach for obvious reasons, the engine would become a copy of X11 driver with added DIB stuffs, which would vanify the (simpler) approach taken. BTW, I'm still convinced that the right approach would be to rewrite X11 driver withe the engine embedded, OR to embed the engine on gdi32 taking it off X11 driver. Well, back to first approach, Jesse's one. It means to make a copy of the source bitmap *before* blitting converting it on same format of destination one. That approach is slower because it means to make a copy /conversion of the source bitmap which can be time expensive. Jesse's solution was to make a conversion of the *full* source bitmap which showed it's first limit on my Autocad testings (the layer manager part) on whith very small parts of a big image are Blitted. That means sometimes hundreds of copy/conversions of a MB sized bitmap just to transfer some 40 pixels a time. not a real speed gain :-) So I decided to limit the copy of the needed lines of source bitmap, with help of GedDIBits/SetDIBits stuffs. Not perfect, but quite faster. *if* working. SetDIBits seems to have some sort of bug when startscan and scanlines don't use the full bitmap's size. I'm not able to test the SetDIBits X11 code, so if somebody can check it that would be of great help to me. GetDIBits works good with those parameters selecting a stripe of full bitmap. Now, the second problem on that approach, which emerged testing the same autocad part. When blitting *from* screen device, there's no real BMP selected onto DC, so the GetDIBits approach is useless. The only way to cope with the problem is to make a (third) intermediate conversion, so DEVICE DC ---bitblt (X11 side)---memory DC (DDB)---GetDIBits--- DIB That means 3 data transfers to make a BitBlt operation from display to a DIB destination bitmap Anyways, even with those bottlenecks, autocad application shows great speed improvements on TT fonts (from unusable to about the same windows xp speed) with no visible slow downs. Ciao Max
Re: Testing DIB Engine - Better blitting and partial ROP3 support
Massimo Del Fedele ha scritto: Hi, I made some changes to DIB engine : 1) Some more consistent DIB type naming and color handling 2) Partial implementation of 256 ROP3 operations 3) Partial ROP3 implementation on blitting (stil no pattern) 4) Some optimizations in blitting code I attach here the zipped patches. Ciao Max I put a new (bugfix) version on bug 421 page. Please use that one for testing, it should have most font error corrected. Ciao Max
Re: tests with new DIB
Evgeny Burzak ha scritto: Hello, I make some tests and it show interesting results: * Archicad 10 and 11 can open plans, crashed of course and unusable, but with WINEDIB=OFF it didn`t work at all. * Flash 8 with WINEDIB=ON render fonts much faster. Screens and logs attached. colors of plans are wrong. Must be grey on white. Well, thank you for testing :-) The bad colors are probably due to missing ROP on blitting; by now bitblt just do a copy from source to dest bitmaps. I guess I'll add ROP handling on next patches. Do Flash 8 have any bugs on display ? Ciao Max
Re: richedit: Removed unnecessary calls to ME_WrapMarkedParagraphs.
Dylan Smith ha scritto: These calls to ME_WrapMarkedParagraphs never do anything, and don't make sense to be called in these places. These places are for ME_MoveCaret, and ME_ArrowHome, which both don't involve any text being modified, and all (direct and indirect) calls to these functions are done after the text has already been wrapped. --- dlls/riched20/caret.c |3 --- dlls/riched20/paint.c |2 +- 2 files changed, 1 insertions(+), 4 deletions(-) This patch broke MTEXT and DDEDT autocad commands, see bug http://bugs.winehq.org/show_bug.cgi?id=17301 Ciao Max
Re: DIB Engine - Patchset separated by original author
Jesse Allen ha scritto: On Sun, Feb 1, 2009 at 9:29 AM, Massimo Del Fedele m...@veneto.com wrote: As asked to me, I have separated the dib engine into a patchset, trying to keep (when possible) the original author's submissions, so Huw Davies, Jesse Allen and me. I had to change some of other author's commits in order to fit my engine and to rebase it on 1.1.14, so I ask both previous authors to check if they agree on the patches. I hope this will help the review, as keeping it rebased on wine tree will become quite hard having it as a separated patchset. Attached here is a zipped patchset, which apply on wine 1.1.14. Ciao Max Hello, I have placed the patches unchanged onto this git page: http://repo.or.cz/w/wine/dibdrv-max.git Hope this helps. Jesse Hi Jesse, I've been out for job for a while, but I don't see many comments about the patch. I guess I'll stop developing the engine for now. It makes few sense to code for something that will probably never be accepted. Ciao Max
DIB Engine - Separated in small patches
As requested I separated the engine in small patches, trying to keep original authors when possible. As the post didn't appear here (problem with zipped files, maybe ?), I've put it on bug 421 page. I whish to know if it can be ok for including on wine tree. Ciao Max
DIB Engine - Rebased on current tree (Takes 2) - Part one - GDI32 patches
As there where some changes on GDI32 in latest commits, previous testing
DIB Engine had to be modified too.
I'm posting here (and in bug 421 page) the 2 needed patches, separated
by GDI32 changes and winedib.drv folder.
In order to keep patches smaller, I dropped the autogenerated
'configure', but leaving 'configure.ac' I guess this is the correct
way, probably an autoconf is needed to regenerate the configure file.
I was asked to separate the commits from Huw Davies, Jesse Allen and me,
but as I changed most of the original author's code It'll be somehow
difficult and, imho, will make few sense. It can be done, but that would
mean to post a great number of patches with the final result quite
different from the original one.
I let of course the original copyright notices inside files; I'd like
original author's opinion if for them is enough.
Instructions on how to enable/disable the engine as the same as previous
post, and are detailed in BUG 421 page.
First part -- GDI32 patches
Ciao
Max
diff --git a/dlls/gdi32/bitblt.c b/dlls/gdi32/bitblt.c
index 4270f51..2bc6178 100644
--- a/dlls/gdi32/bitblt.c
+++ b/dlls/gdi32/bitblt.c
@@ -2,6 +2,8 @@
* GDI bit-blit operations
*
* Copyright 1993, 1994 Alexandre Julliard
+ * Copyright 2007 Jesse Allen
+ * Copyright 2008 Massimo Del Fedele
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -37,6 +39,76 @@ WINE_DEFAULT_DEBUG_CHANNEL(bitblt);
/***
+ * BITBLT_ConvertDIBtoDDB
+ *
+ * Creates DDB that is compatible with target hdc.
+ */
+HBITMAP BITBLT_ConvertDIBtoDDB( HDC hdc, HBITMAP srcBmp )
+{
+BITMAPOBJ *srcBmpObj = GDI_GetObjPtr( srcBmp, OBJ_BITMAP );
+BITMAPINFO *bmi;
+HBITMAP hBmp = NULL;
+
+if (!srcBmpObj)
+return NULL;
+
+bmi = HeapAlloc( GetProcessHeap(), 0, sizeof(BITMAPINFOHEADER)+
+ sizeof(RGBQUAD)*srcBmpObj-nb_colors );
+if (!bmi)
+goto error;
+
+memcpy( bmi-bmiHeader, srcBmpObj-dib-dsBmih, sizeof(BITMAPINFOHEADER) );
+memcpy( bmi-bmiColors, srcBmpObj-color_table, sizeof(RGBQUAD)*srcBmpObj-nb_colors );
+hBmp = CreateDIBitmap( hdc, bmi-bmiHeader, CBM_INIT, srcBmpObj-dib-dsBm.bmBits, bmi,
+ DIB_RGB_COLORS );
+HeapFree( GetProcessHeap(), 0, bmi );
+
+error:
+GDI_ReleaseObj( srcBmpObj );
+return hBmp;
+}
+
+/***
+ * BITBLT_ConvertDDBtoDIB
+ *
+ * Creates DIB that is compatible with the target hdc.
+ */
+HBITMAP BITBLT_ConvertDDBtoDIB( HDC hdc, HBITMAP srcBmp )
+{
+HBITMAP res = NULL;
+BITMAP bitmap;
+BITMAPINFO *bi;
+void *bits = NULL;
+
+if (!GetObjectW( srcBmp, sizeof(bitmap), bitmap )) return 0;
+
+bi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + 256 *
+ sizeof(RGBQUAD));
+if (!bi) return 0;
+
+bi-bmiHeader.biSize= sizeof(bi-bmiHeader);
+bi-bmiHeader.biWidth = bitmap.bmWidth;
+bi-bmiHeader.biHeight = bitmap.bmHeight;
+bi-bmiHeader.biPlanes = bitmap.bmPlanes;
+bi-bmiHeader.biBitCount= bitmap.bmBitsPixel;
+bi-bmiHeader.biCompression = BI_RGB;
+bi-bmiHeader.biSizeImage = 0;
+
+/* Get the color table or the color masks */
+if (!GetDIBits(hdc, srcBmp, 0, bitmap.bmHeight, NULL, bi, DIB_RGB_COLORS))
+goto end;
+
+/* Create bitmap and fill in bits */
+res = CreateDIBSection(hdc, bi, DIB_RGB_COLORS, bits, NULL, 0);
+if (bits)
+GetDIBits(hdc, srcBmp, 0, bitmap.bmHeight, bits, bi, DIB_RGB_COLORS);
+
+end:
+HeapFree( GetProcessHeap(), 0, bi );
+return res;
+}
+
+/***
* PatBlt(GDI32.@)
*/
BOOL WINAPI PatBlt( HDC hdc, INT left, INT top,
@@ -74,15 +146,43 @@ BOOL WINAPI BitBlt( HDC hdcDst, INT xDst, INT yDst, INT width,
if (dcDst-funcs-pBitBlt)
{
+HBITMAP origSrcBmp = NULL;
+
update_dc( dcDst );
dcSrc = get_dc_ptr( hdcSrc );
if (dcSrc) update_dc( dcSrc );
+/* Try to keep driver physDevs consistant */
+if (dcSrc dcSrc-dib_funcs dcDst-dib_funcs)
+{
+if (dcSrc-funcs == dcSrc-dib_funcs dcDst-funcs == dcDst-drv_funcs)
+{
+/* Convert source DIB to DDB */
+HBITMAP ddb = BITBLT_ConvertDIBtoDDB( hdcDst, dcSrc-hBitmap );
+if (ddb)
+origSrcBmp = SelectObject( hdcSrc, (HGDIOBJ)ddb );
+}
+else if (dcSrc-funcs == dcSrc-drv_funcs dcDst-funcs == dcDst-dib_funcs)
+{
+/* Convert source DDB to DIB */
+HBITMAP ddb = BITBLT_ConvertDDBtoDIB( hdcDst, dcSrc-hBitmap );
+if (ddb)
+origSrcBmp = SelectObject
Re: Updated DIB Engine
Jesse Allen ha scritto: The DIB engine is really unlikely to help starcraft the game at all. However, try staredit.exe ;) Jesse The engine in its current state will, IMO, help just those apps that don't require real time graphics but do make many drawings on dibs, so requiring many conversions between dib itself and X11. For example, apps with tons of text drawings on dibs will benefit greatly with the engine. Optimizing blitting will increase the number of such apps. Keep in mind that by now the blitting is a slow sequence of read pixel-convert format-write pixel, with no care if source and destination bitmaps have the same format, for example, which could be handled by simple memmove. It doesn't handle clipping, either, nor ROP operations. For Autocad (with many TT fonts on drawing) the speed gain is something like 50x - 100x, depending on the amount of text objects I don't know staredit, but I'd like to know what is the speed increase :-) Ciao Max
Re: Updated DIB Engine
Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ? Ciao Max
Re: Updated DIB Engine
Reece Dunn ha scritto: 2009/1/27 Massimo Del Fedele m...@veneto.com: Any opinion about this one ? Could it be a good candidate for inclusion in wine tree ? Hi, I have used this with StarCraft, running it with and without the DIB engine enabled. I find the environment variable makes it very easy to switch between them during testing, so I am for this (as well as being able to set the default option via the registry). Thanx, that was what I wanted to have :-) My experience with the game is that it is actually slower and has a noticible stutter when compared to the non-DIB engine version. This does not mean that I am opposed to this going in, as I know that the blitting code is not yet optimised. In fact, I am for this to go in (provided that Alexandre accepts it). Yep, the blitting code is just a placeholder to make most apps run, not an optimized one. Making it optimized is trivial but requires many code lines, so before proceeding I thought to wait for approval of the way the engine is done. The same is for text stuffs. The only thing I would say is to break it up. For example, there are bits that you have taken from Jesse and Huw's efforts that are various isolated patches. These should be sent in a git patch format so that the authors can be attributed in the Wine git tree as well as being in the Copyright notices. Well, that one could be only partially done, because I modified most of both Huw and Jesse's code. I let Jesse and Huw's copyright notices because of that, but going back from original code, joining the 2 and adding my mods by mean of many git patches would be overkilling. Even more, both trees were somehow outdated in respect to actual wine tree, so the automatic merge didn't work for some parts of code. I'd see easier to put the 3 names on each patch when (if) merged with main tree. Aside from that, if you could break the DIB patch into smaller logical chunks it will be easier to review and get the patches in. Well, that also can be partially done : 1- First GDI32 patch, the one that allows to insert DIB Driver, without blitting (mostly from Huw's tree, but driver loading displaced from SelectBitmap to CreateDC by me, with some additions to avoid crashes if driver is not present. 2 - Starting dib engine, without blitting and (maybe) many stubs, but with primitives and some basic stuffs, mostly from Huw's tree, some small patches by me 3 - Blitting, which requires both patching GDI32 again and adding the code to DIB driver, and all stubs; all that mostly from Jesse's tree, many patches by me 4 - Initial text and font implementation, by me 5 - Registry and environment variable stuffs, by me Most chunks need to span over more source files. After that, I guess the code is defined enough to be opened for completion. Have you asked Alexandre on IRC what he thinks of the design? No I'm not using IRC since ages :-) Is this the way to ask him ? - Reece Ciao and thanx for comments ! Max
Re: Updated DIB Engine
Ben Klein ha scritto: I'm still opposed to adding an environment variable for something so simple (an enable/disable flag). It just seems like extra work for no benefit to me. I'm sure we can all agree that the registry is a suitable place for the setting. The environment variable allows testing on the fly of enabled/disabled engine, AND allows to run some apps with engine enabled as others with engine disabled. Having to run regedit just to test an app run is overkilling, IMHO. BTW, the environment variable is fully optional, you can but you haven't to use it, if you choose so. just set the registry variable and all is ok. Isn't the idea that the DIB engine will only be used as needed, and will be good in all cases where it's used? If that's the case, it's not too important having on-the-fly per-application enabling/disabling (whereas WINEDEBUG and WINEDLLOVERRIDES can be VERY useful). The engine, as it is, is by far less than complete, so very few apps do benefit of it, one of them is autocad, at the moment. I guess most apps are penalized by the engine in present state. So I really don't see the point of avoiding an environment var which, BTW, is checked just ONCE and on first loading of the DIB driver, and costs just about 5 lines of code. Max
Re: Updated DIB Engine
Roderick Colenbrander ha scritto: Having an environment variable is a minor detail. Sure it should be used transparently but it will take a lot of time (when the architecture is correct) to enable it by default. IMHO the engine will (if it ever enters on main trunk) stay disabled by default for long, long time. Having it to work ok to the same extent as is gdi32/winex11 now will take a lot of time and patches. A lot of performance tuning would be needed as it could seriously decrease performance in a lot of cases. I agree completely on this The gain / loss depends on what type of calls the program is making. If it draws lets say on a line by line basis then software rendering could help. But if it uses a smarter method a single X call might be more efficient. More precisely, it will depend on the degree of optimization of dib engine code which, by now, is close to zero. When blitting will be optimized, for example, the performance increase will be huge. Further there are also other tradeoffs e.g. when the latest version of the drawable is in X then it might not be smart at all to copy it back to the DIB engine and let it do the rendering just because we have a DIB engine. The cost for the download and reupload to the videocard might be much higher. The engine, as it is now, just renders on DIBs, when they're in memory, not on DDB. So it shouldn't penalize at all the rendering of drawables already owned by X. It'll just avoid the double copy between dib and x ant the way back just to, for example, render some text. That happens now in autocad, for example, which slows it down by a factor off 100. The only mixed behaviour is when you're blitting a dib onto a ddb (or the way around), but even then the code converts the source bitmap to the destination format and then uses the best way to blit it. It could even be optimized by blitting without converting before, but it would need some hard intervention on GDI code, which is what I wanted to avoid. Ciao Max
Re: Updated DIB Engine
Erich Hoover ha scritto: I haven't looked into your implementation in much detail (I need more hours in a day, I swear), but would it be possible to pass all the stubs on so that unimplemented functionality still works even if it's dog slow? It'd be nice if we could take advantage of the implemented features, still be able to handle everything, and then spew a FIXME: Help Wine run faster by implementing this function in the DIB engine! for features that are not handled yet. (yeah, yeah, I want my cake and be able to eat it too) Erich Hoover ehoo...@mines.edu mailto:ehoo...@mines.edu Well, by now many functions are stubbed (with disabled FIXMEs for speed), and 3 apps I've tested on it works ok. Some bad graphics, but mostly usable. You can test it easily and, if you like, you can enable all the stubs FIXMEs uncommenting a #define on header file. Ciao Max
Re: Updated DIB Engine
Erich Hoover ha scritto:
What I was trying to say is if you could have something like this for
all the stubs:
BOOL DIBDRV_AlphaBlend( DIBDRVPHYSDEV *devDst, INT xDst, INT yDst, INT
widthDst, INT heightDst,
DIBDRVPHYSDEV *devSrc, INT xSrc, INT ySrc, INT
widthSrc, INT heightSrc,
BLENDFUNCTION blendfn)
{
FIXME(reverting to slow behavior!\n);
return TheOldBehavior-AlphaBlend(...);
}
While I'm obviously not greatly familiar with this code, it seems like
the engine would have a better chance of being successful if
unimplemented features fell back to the old behavior. It seems like
that would allow you to gradually transition over to the integrated DIB
engine a little bit at a time, rather than having a lot of unavailable
features that would all need to be implemented before the integrated DIB
engine could be turned on for everyone. Even if you had to create a
special surface and copy the bitmap back and forth every time you had to
revert to the old behavior it seems like it would at least provide a
good testbed.
Erich Hoover
ehoo...@mines.edu mailto:ehoo...@mines.edu
Well... almost impossible by keeping GDI and driver structure separated.
You call winex11 whith its physDev, and WineDib with it's own
(different) physDev. Either don't have knowledge of other's structure
(they're opaque pointers), nor they have e pointer of each other.
So, from Dib driver is impossible to call an x11 driver function.
That could be done directly from inside GDI32, but would require some
deep changes on it, which I wanted to avoid.
BTW, I'm still thinking that the better way of adding the dib engine
would be from inside gdi32, but whis would mean to change deeply a code
that is working good.
Another possibility would be to add a pointer to x11 physDev inside the
Dib physDev that one would be easier, but hacky.
Ciao
Max
Updated testing DIB Engine
I did some update on the engine, I tried to post it here as a zipped patch, but didn't got published So I've put it on bug 421 page with instructions on how to use it. I'd like to have some feedback if the implementation way is the right one. Ciao Max
Re: $200 bid for autocad support
Dan Kegel ha scritto: http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1087309txtFromURL=AId_512725 Someone's got to break the bad news to him about the likely cost... Uh... maybe he forgot some nulls on the end... :-)
Re: Testing DIB Engine (second part)
I haven't still any clue if the way I started the DIB engine has the correct approach, I mean if I should follow this way with the hope to have it included in main tree or not Can please somebody tell me something about ? Ciao Max
Re: Testing DIB Engine (second part)
Roderick Colenbrander ha scritto: I haven't still any clue if the way I started the DIB engine has the correct approach, I mean if I should follow this way with the hope to have it included in main tree or not Can please somebody tell me something about ? Ciao Max I would recommend you to visit #winehackers and start asking there. AJ is there too. I believe it was mentioned at WineConf that also Jesse his design wasn't good. Roderick Well, my design is a mix between Jesse's and Huw's ones, more the latter than the former. BTW, both designs are similars in concept. Well I'll wait for some more suggestions :-) Thank you for answer Ciao Max
Re: Testing DIB Engine (second part)
Jeff Zaroyko ha scritto: On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele m...@veneto.com wrote: Here the second part, it contains winedib.drv code and changes to Makefiles. Still no way to enable/disable the engine, besides of deleting the .so inside dlls/winedib.drv. I'll wait for some feedback before going fourther. Ciao Max Instead of deleting it, you could simply set winedib.drv to disabled in winecfg? -Jeff Yes, of course. The final idea is registry/environment var; I posted the patch quickly because many people asked for and I've got no time to work on it on these days. Ciao Max
Re: Testing DIB Engine (second part)
Paul Vriens ha scritto: Massimo Del Fedele wrote: Here the second part, it contains winedib.drv code and changes to Makefiles. Still no way to enable/disable the engine, besides of deleting the .so inside dlls/winedib.drv. I'll wait for some feedback before going fourther. Ciao Max Hi Max I don't think this should have gone to wine-patches but to wine-devel instead. After all it's a proof of concept and not a complete solution. Well, I asked about it before posting, but I didn't get a clear answer on where to post it. Next time it'll be on devel. Could you also zip these huge things up in the future (mail is now 1217KB)? Ok, I didn't know if it is correct or not to zip the patches. Ciao Max
DIB Engine
As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? Ciao Max
Re: DIB Engine
Roderick Colenbrander ha scritto: As my DIB engine is becoming usable (I already use it on Autocad for my job), I'm thinking to publish the patches. As it's still not complete, I'm thinking to add a way to enable it on demand with registry and environment variable : export WINEDIB=ON activates it export WINEDIB=OFF deactivates it if no environment variable, it checks a registry key (I'd like to have some suggestion on where to put it). If no environment variable nor registry entry are present it'll be disabled (by now) as is for testing purposes. How should I publish it ? A big unique patch, 2 patches, one with the (small) changes in gdi32 and another big one with the engine itself, or many small patches ? Is it right to put on wine patches list ? Ciao Max I would say a registry key is fine to turn it on/off but this is a minor detail. The most important thing is that the architecture is 100% correct. Implementing drawing functions in software isn't that hard but getting the design right is very, very hard. I would suggest to post a big patch for review or so. Not to discourage you but I fear that the design might still not be good. Roderick Thanx for the answer. I'll polish a bit the code and publish a big patch here. BTW, I followed Jesse Allen's and Huw Davies way, as I was told it should be the right one... Ciao Max
Re: DIB Engine
Austin English ha scritto:
On Tue, Dec 23, 2008 at 10:44 AM, Massimo Del Fedele m...@veneto.com wrote:
As my DIB engine is becoming usable (I already use it on Autocad for my
job), I'm thinking to publish the patches.
As it's still not complete, I'm thinking to add a way to enable it on
demand with registry and environment variable :
export WINEDIB=ON activates it
export WINEDIB=OFF deactivates it
if no environment variable, it checks a registry key (I'd like to have
some suggestion on where to put it).
Go for something similar to our other registry keys:
http://wiki.winehq.org/UsefulRegistryKeys
Maybe HKCU\Software\Wine\X11 Driver\DIB Engine {Y/N}
?
That one seems perfect, thanx !
I think I'll add also an environment variable, so we can switch on or
off the engine on the fly.
Ciao
Max
Re: Get font file (full) path from HFONT
Dmitry Timoshkov ha scritto: Massimo Del Fedele m...@veneto.com wrote: In order to use Freetype library I need to get font file full path from an HFONT handle. Is there a simple way to do it or should I scan the registry/font dirs to pair font faces/font paths ? Do you need this under Wine? In the app code, or Wine code? For which purpose? It was in wine code, for my dib driver. But it's (to some extent) solved by examining gdiFont list passed by SetFont() function, it already contains an FT_Font handle for every used font (I think). Weird way to do it, but I couldn't find any simpler one BTW, I still don't understand the purpose of gdiFont parameter, and in which cases it can be null. Ciao Max
Re: wine-1.2 release criteria?
Rolf Kalbermatter ha scritto: It may be ugly in some ways but incorporating it in wineX11.drv has the big disadvantage that it would not be easy to leverage it off to other possible display drivers such as the quartz driver. Windows 2K/XP does appear to do it mostly in the Eng... GDI functions which would have been another possibility. Vista changed the entire GDI/display driver business seriously again and I have no idea how it does work there. Rolf Kalbermatter Well, imho the right way would be to replace winex11.drv with a driver with pluggable backends, which could do all DIB stuffs as dib engine and forward to the backend(s) all device drawings. Or, even better, change gdi32 to hook to different drivers for DIB and DDB bitmaps. I mean, every gdi function should test if bitmap is a DDB or a DIB and use the appropriate driver. What I'm doing now (and what's done in Jesse's and Huw's engines) is an hack that swaps driver's hooks depending on bitmap type just on SelectBitmap() function, which has many disadvantages : 1) BitBlt functions (and maybe any call that operates on 2 BMPs) must check whether both BMPs are of the same kind, OR change one of them, in order the correct driver to operate (which is indeed done in Jesse's and in my engine). 2) CreateDc() and similars are called twice, once for every driver, and the DIB one must be done on SelectBitmap(), which is ugly. BTW, all that would require some major cleanup of gdi code, which I guess nobody would like Max
Get font file (full) path from HFONT
In order to use Freetype library I need to get font file full path from an HFONT handle. Is there a simple way to do it or should I scan the registry/font dirs to pair font faces/font paths ? Ciao Max
Re: wine-1.2 release criteria?
Vitaly Lipatov ha scritto: В сообщении от 15 декабря 2008 Massimo Del Fedele написал(a): ... I'm (slowly) going on with dib engine, I choose at first Jesse's one as starting point because it had a source file structure I liked more. Please if you do something with DIB Engine, publish your git repository. We (Etersoft) do some tests and patches too, and I am wondering why do not contact with our developer c...@etersoft.ru ... DIB engine is progressing a bit... solved the (I hope) last crash problem, now BitBlt works, but still unoptimized. Fonts partially work too. I can run Autocad with DIB engine and, even with slow bitblt and unoptimized font rendering, the speed gain on True Type font display is impressive. I' ve not published the git because I'm still changing some core stuffs, and I want it useable and stable enough before publishing. StretchBlt is still not done, and that's a must, IMHO. When I'll get these stuffs ready : Optimized BitBlt StretchBlt Completed font rendering Clipping, maybe... I'll publish the git. A note : my DIB engine now includes both Jesse Allen's and Huw Davies ones, merged to take the best of both. BTW, i'll finish it following this way, but I still think the best way would be to include it in wineX11.drv. Using the mixed driver approach, with different function pointers and physical devices depending on bitmap content is, imho, an ugly way to solve the problem. Ciao Max
Re: wine-1.2 release criteria?
Reece Dunn ha scritto: 2008/12/15 Dan Kegel d...@kegel.com: - DIB Engine As mentioned in http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine Massimo picked up Jesse's DIB engine code and has been trying to use it with Autocad. He says he's starting to get fonts working. (It's surprising that he chose Jesse's 2007 implementation rather than Huw's 2008 implementation, but he said Jesse's seemed more usable at the moment, even though Huw's looked better in some ways). What is the status of these? As far as I can tell, there are a few changes that could be merged into wine proper, without pulling in the respective DIB engines: Huw -- gdi32: The dib colour table should always have 1 bpp entries (for bpp = 8). http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=4c9188ee5e8c56aa0fb5719973663ac304ed994e Huw -- gdi32: Don't use biSizeImage for a BI_BITFIELDS dib. http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=892bd17b188f8afa2303030e297a54ae1221190b Jesse -- gdi32: Keep physDevs consistent to driver in Blt calls http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=754f91a30771a76e4704397f387d355a7fd06386 Jesse -- gdi32: Pass color table to drivers with SelectBitmap http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=9b60e63fd31877c7350c757bf4e005eb81f658e2 From there, it depends on whether Huw's approach, Jesse's approach or some other approach is the way to go. It would be useful to try and get the 'core' DIB engine architecture in first, so that any necessary changes to the architecture can be made before too much time/effort is spent on this. The core should have an option to turn on the DIB engine routing, so that it can live in the main tree without breaking existing applications. Once the core architecture is in place, it will then be a matter of filling in the blanks. From there, the selection logic (which should be fairly small -- a registry key check, like the Direct3D fbo setting?) can be removed. Or am I missing something? - Reece No, you aren't missing much :-) I'm (slowly) going on with dib engine, I choose at first Jesse's one as starting point because it had a source file structure I liked more. Now I'm merging Huw's one, it has ROP support, pen and brushes Stuffs are going on. I paused the font code for a while, it's very basic by now but I wanted to see something in order to test the speed difference in autocad which is awesome. The engine still have some bugs that cause it crashing sometimes... I'm investigating about it before going on. When I'll get something stable I'll post the code somewhere. About disabling/enabling the engine, there are 4 choices : 1-by registry 2-by environment variable 3-by ./configure 4-simply removing winedib.dll.so; driver goes thru x11 if it doesn't exist. Ciao Max
