Whither DWT?

Daniel Keep daniel.keep.lists at gmail.com
Fri May 5 06:38:23 PDT 2006

freeagle wrote:
> Daniel Keep wrote:
>> Jari-Matti Mäkelä wrote:
>>> freeagle wrote:
>>>> Daniel Keep wrote:
>>>>> What is worse, what are you going to do about Vista?  When that comes
>>>>> out, all your work on the XP skin has to be re-done from scratch.  And
>>>>> even then, given that Vista uses all those transparency effects,
>>>>> will it
>>>>> even be possible without a major rewrite?
>>>> - actually, with a good design, it could be possible to add modify
>>>> skins
>>>> and themes with just a different set of images, maybe small code
>>>> rewrite. Id never accept a toolkit that need to rewrite whole widget
>>>> set
>>>> for every available theme/skin it supports. About those transparency
>>>> effects, OpenGL has alpha blending, so i dont see what major rewrites
>>>> you are talking about. But i must say i havent tried vista yet, so im
>>>> not even absolutely sure what transparency effects you are talking
>>>> about.
>>> AFAIK application windows in Vista have a < 50% alpha value and a lame
>>> distortion effect on the window title bars by default. It's easy to do
>>> these things in OpenGL. You can even create animated, multitextured
>>> backgrounds with bump mapping without any greater problems - even with a
>>> terrible widget set design.
>> You most certainly can do those things in OpenGL.
>> Except Vista's desktop is composited using DirectX, so you can't simply
>> "render" the window using OpenGL and expect it to blend with everything
>> else.  Which means you would have to work out some way to grab all the
>> pixels underneath the current window, and I'm not entirely sure how you
>> would do that.
>> Of course, once you've done that, you can load the pixels into OpenGL,
>> then render, and then... oh wait, Vista turns off desktop compositing as
>> soon as you try to use OpenGL.  Which means as soon as you fire up your
>> windowed OpenGL app... all the desktop compositing and Vista theme
>> disappears.  Oops.  Now your program looks out of place anyway >_<
>> Unless of course Microsoft changes their mind about OpenGL... bloody
>> monopolists... stupid DirectX...
>> Anyway, my original motive was more directed to the "we should make a
>> self-rendered toolkit" vs "no!  we should make a native toolkit!"
>> comments.  I think we need at least once of each, since there are things
>> each toolkit can't really do.
>>     -- Daniel
> - maybe i say something stupid, but...
> - i suppose vista wants back compatibility with apps renderes with GDI.
> and GDI can do transparent stuff too. Actualy, both GDI and OpenGL work
> with the device context, which contains/points to (dunno the exact
> internals) to a pixel buffer hes connecte to. So you dont have to get
> all the pixels first, blend them and finally render them since they are
> already included in the device context. If they are not, i suppose theyd
> need a major rewrite of GDI too, and i dont think they can afford it.
> And i think that you can combine GDI rendering with Direct3D rendering,
> as well as GDI + OpenGL in current releases of Windows. So, i havent
> tried it yet, but i think that OpenGL + Direct3D could work too. Think
> Im going to find out :)

Fair enough.  But like I was saying, if you want your toolkit to look
like the host system, I imagine it would be easier to just wrap the
system's API :P

That said, I've been doing some searching, and if you wanted to do
borderless, translucent rendering in Windows, you might be able to get
away with using GDI and "layered" windows.  Some interesting stuff in
MSDN on it.

One of these days, I'll get around to writing that Konfabulator clone
I've always wanted :P

	-- Daniel


a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

More information about the Digitalmars-d-dwt mailing list