28 dec 2010 kl. 13.19 skrev Helmut Karlowski: > When? Which version? 0.999, compiled by you about a week ago. If there is a new one that I haven't received, I would be happy to try it to see if the issue I've encountered has gone away. > What's not stable? There is a 1-pixel inconsistency when drawing objects, which causes the position to change based on the method used when redrawing it. > I think it's fixed since weeks. You fixed some other bugs, which manifested itself when using only SIZER. But it seems this introduced some side effects which I'm trying to illustrate here. > Icannot reproduce the displacement you mention, so I don't see a reason to change anything. I have attached code which reproduces the problem, along with screenshots made when executing said code on your 0.999 and on the official 0.998. Lonny has tested it on N.AES, but couldn't save screenshots since the screenshot app is blocked by alert boxes. He confirmed however that the redraw artifact isn't there on N.AES (i.e. it matches 0.998). I have included a suggested workaround (on the application side) in the code (change the #if 1 to #if 0 in the code and recompile). However this means the entire toolbar is redraw even though only a single object needs to be updated, and that would be unfortunate and sub-optimal. > Please 'prove' that there's something seriously wrong and I will look at it. I sent you screenshots about a week ago. I've attached new ones + code to reproduce the problem as to clarify this matter further. > 1. N.AES does not rule (for me) We need some point of reference here. The reason I compare with N.AES and 0.998 is because they're the closest comparison we have for a modern AES - not counting MyAES because I can't get it to work on my machine (probably an error on my behalf, however). Toolbars are working in N.AES, and has been working for quite a while. So in that sense, N.AES rules. Apart from that, I generally prefer XaAES. All I want is for XaAES to have a fully working toolbar implementation, and I'm trying to contribute to make that happen. I do that by testing the toolbar functionality, providing code to reproduce problems, and providing screenshots. That's the only way I can contribute at the moment, and I'm under the impression that testing the toolbar implementation is a good way of finding problems in the implementation. > 2. Your issue is pure cosmetic and does not affect functionality (and it's gone) The displacement is different depending on how you redraw the object (i.e. via the rectangle-list, re-attaching the toolbar, or letting XaAES redraw the toolbar when moving the window). This means it's not a minor cosmetic flaw, and it causes artifacts on screen. It's not a matter of personal taste, it's a redraw error. > 3. I won't revert anything unless it breaks existing apps You said yourself that you've never encountered more than 1 application which uses toolbars. Then you decided to change the visuals of the toolbar. I never asked you to do that, both you and I know it introduced side effects which we've talked about earlier. I'm using toolbars in an upcoming project, and I think it's a great opportunity to test this stuff properly. And so far I've found several bugs, and we've had a good cooperation when solving them. I believe my latest finding was introduced with the changes in the toolbar visuals, because it doesn't happen on 0.998. I don't say this to bash your work, because I think it's really good. It just needs to be tested and bug fixed. > 4. Fee free to fix things you don't like in XaAES I've come up with code which reproduces several problems, I've produced screenshots and code to reproduce the problems. That's my way of contributing, and personally I can't see how that can be wrong in any way(!). All I want is a working toolbar implementation, because I'm using toolbars in my projects. The work you've done is great - it needs to be tested and bug fixed, that's all. That's not critisism, that's the law of nature - no code on the planet is free of bugs. The reason I requested this particular code to be rolled back (note that I say rolled back - not ditched) was because I wanted a fully working toolbar implementation in 1-17. If it's not rolled back, or if this bug is not fixed (if it is a bug), then that will not be the case, and I think that would be unfortunate. When working, the code could be re-introduced again (because it does look better than the old code once it's fully working). I was under the impression that CVS could make this possible in some neat way, but maybe I was wrong. Check the attached files, please. Pay attention to the toolbar icon on the screenshots, and watch them in order. Begin with 'helmut_0999_x.png', then check 'official_0998_x.png'. The outline of the mask matches that of the icon data. On the 0.999, there is residue of the selected icon, and it shouldn't be there - because when redrawing the unselected icon, the new data should completely cover the old data (after all - this is the *same* object!!!). Compare this with 0.998 and N.AES, where it doesn't happen. Again this is not a matter of personal taste - this is a displacement which causes artifacts. Hopefully it is an error in *my* code and not in XaAES, but I wouldn't be having this conversation if I didn't suspect that it was a problem in XaAES. If it's an error on my behalf, I'd be the first one to apologize if I wasted your personal time. But again, my intention is only to contribute, and since I've been testing the functionality in question quite extensively lately I think my input could be useful. My 0.999 is from Dec 18 2010. My 0.998 is from May 6 2007. Lonny tested it successfully on the most recent version of N.AES and Odds last unofficial build (0.998 alpha, from Apr 15 2006). I'm using Aranym right now. -- PeP Note: The extra arrow sprites on the screenshots seems to be an Aranym+fVDI problem. Please ignore them (it doesn't happen on my real machines). Another note - the Alert icons looks very weird on my 0.999 build compared to 0.998 (this is also evident on the screenshots).
Attachment:
makefile
Description: Binary data
Attachment:
main.c
Description: Binary data
Attachment:
test.prg
Description: Binary data
