文件列表:

source\creatergn.h (485, 2004-03-19)
source\mytypes.h (2505, 2003-04-29)
source\resource.h (494, 2004-03-19)
source\BmpPixBuf.hpp (765, 2004-03-19)
source\BmpPixBuf.cpp (2634, 2004-03-19)
source\creatergn.cpp (3378, 2004-03-19)
source\main.cpp (2863, 2004-03-19)
compiler_asm\BmpPixBuf.asm (12984, 2004-03-19)
compiler_asm\creatergn.asm (13623, 2004-03-19)
compiler_asm\main.asm (12623, 2004-03-19)
bin\region.exe (200704, 2004-03-19)
bin\takeshape.exe (1024000, 2004-03-19)
source\gfx\background.bmp (160578, 2004-03-19)
bin (0, 2004-03-19)
compiler_asm (0, 2004-03-19)
source\gfx (0, 2004-03-19)
source\region.rc (1941, 2004-03-19)
source\region.sln (901, 2004-03-19)
source\region.vcproj (4299, 2004-03-19)
source (0, 2004-03-19)

Hey everybody, here's my little attempt at custom-shaped windows, with "somewhat more optimal" code than what I've seen floating around :) It's based on code by SubEvil from the win32asmboard, from this thread: http://board.win32asmcommunity.net/showthread.php?s=&threadid=17519 . I think that code is based on even older assembly custom-shape code which is probably based on some cruddy C code (et cetera). At least I'm pretty sure I've seen the sample image in other custom-shaped window samples, and I've seen the same basic algorithm in a number of assorted languages - basic, delphi, C. The wide-spread algorithm used has a number of problems. It calls GetPixel, which will always be slower than "doing things right". The Win32 GetPixel is painstakingly slow, probably because it does color correction etc. SubEvil fixed this by doing some EnterGetPixel, NewGetPixel, ExitGetPixel code - the core algorithm stays mostly intact, and the speedup is nice. It still does (New)GetPixel calls though, and the algorithm uses CombineRgn to combine the region strips. This is not optimal :P (But at least a lot better than the average code floating around, and times better than the worst-case basic code that does CombineRgn for *every* transparent pixel, instead of finding strips). But well, I present to you... *drumroll*... a "pretty good version" :) The bitmap data is accessed directly - no GetPixel, no "A lot faster GetPixel". There's probably still some minor optimizations that could be done with regards to the buffer access, but the compiler generates pretty decent code. Next, instead of constantly calling CombineRgn, I construct a list of RECTs in memory (dynamically growing array), and finish off with a call to ExtCreateRegion. The result is pretty good - the following test results from an athlon700 running Windows XP (ran a few times, lowest values selected): Old/New/"Smart": 871ms, 110ms, 861ms My Optimized algo: 20ms (the "smart" algorithm is the ExtCreateRegion stuff, but still using GetPixel - it's easy to see which routine was the 'sinner'). There's still room for improvement - a little extra could probably be squeezed out of the code by doing a (proper) assembly implementation, with a smarter strip-scanning algorithm. Pixbuffer access could probably be optimized a bit as well. And perhaps there's even different ways of constructing the region data that might be better. I'm rather satisfied with the current results though, so I probably won't bother doing any of this myself. I'll probably clean up the code somewhat, though - the BmpPixBuf is currently very very hackish and dirty, with only some functionality implemented (etc) - and there's bound to be some GDI leaks around. The archive includes the executable from the "takeshape" code from SubEvil (with my "smart" version added, and timings changed to miliseconds instead of cycles), and my own version. Furthermore there's the C/C++ source code, and the generated compiler listings. Have fun :) Oh, by the way - some other interesting things to mess around with, would be hand-creating some "optimal" regions, and see whether this has effect on speed and "move trails". Windows does seem to do some region optimizing on the call to ExtCreateRegion, but generating "optimal" region data is a NP-complete problem, and thus can't be done in a "real-time" API call. It would be interesting to know whether it's worth to pre-create "optimal" region data and include it with the program, or if you might as well use the current method of runtime region data creation. (C) 2004/03/19 - http://f0dder.has.it - f0dder(A)druk.nu

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：