Quote:Original post by jyk
And while we're at it, here's a feature request: in Windows, please make it easy to continue to re-render the scene when the window is being dragged! :) Although it seems I'm somewhat alone in caring about this, it really bugs me when dragging a window offscreen and then back on erases part of the window or causes a 'smearing' effect. This really isn't very polished, IMO, and in a native Windows/D3D app it's a problem that's easily fixed. With SDL (1.2.x) on the other hand, the only way to keep rendering when the window is being dragged is by using one of a couple of hacky workarounds. (I'm not sure how SFML behaves in this regard, but I seem to remember that it also 'smears' when you drag the window around.)

There is no easy way to do this in case of event polling main loop (in contrast to callback main loop). That is because when user moves or resizes window, it blocks and passes WM_PAINT messages directly to MsgProc. Why would you need it, anyway?

Quote:There is no easy way to do this in case of event polling main loop (in contrast to callback main loop).

I'm not entirely sure that's true. I've managed to do it with SDL using a couple of different methods. Now, both involved callbacks in one form or another, so I won't argue with you there, but I don't see why it couldn't be incorporated into an API with a polling-based event system.

Quote:That is because when user moves or resizes window, it blocks and passes WM_PAINT messages directly to MsgProc. Why would you need it, anyway?

Are you asking why you'd want to draw in response to WM_PAINT messages?

Anyway, yes, I know why it happens :) That's not the issue. The issue as that SDL doesn't provide an easy way to respond to the WM_PAINT messages when they arrive.

As you already know, when a window drag commences, Windows blocks and passes WM_PAINT messages back to the handler periodically as needed. Your standard D3D-based application (for example) will render in response to those WM_PAINT messages.

If you don't render in response to those messages, then if you drag the window offscreen and then back onscreen again, the area that was offscreen remains blank until the window drag is completed (or, in some cases you get a 'smearing' effect instead). If you *do* render in response to those messages, that doesn't happen; the image remains intact regardless of where you move the window. (This is true in Windows XP, at least.) It's the later behavior that's preferred, IMO, and is what I'd like to see supported in a Windowing API.

If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/

Quote:Original post by jyk
If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/

Just stopping by to voice my support, I would definitely appreciate such functionality. I agree that it's mostly a matter of aesthetics and polish. Exposing the user to some glitchy graphics junk when he is moving the window just isn't pleasant and makes the application feel less robust.

Quote:Original post by jyk
If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/

Well, it will not happen at all when using composited desktop (Aero on Windows Vista and Windows 7). And that is what most users will use in the near future.

I also want to keep API clean. If I'm using event polling main loop (which is more convenient, and also does not introduce troubles with callbacks into C++ methods), I will prefer to stick to it, and not introduce any "special" behavior to fix Windows API problem. We can all say thanks to Microsoft for that. Why would they make a PeekMessage function and still deliver some messages directly by a callback? Makes no sense to me.

And games usually run fullscreen, so this is not an issue. Windowed mode is useful for development and that single flaw is not so important.

So, to summarize: I also like aesthetics and polish, but this one just not worth the burden. :)

I'd be nice if it doesn't tie you to using OpenGL, alot of the current cross platform windowing solutions seem to force OpenGL upon you.

Quote:Original post by AndyPandyV2
I'd be nice if it doesn't tie you to using OpenGL, alot of the current cross platform windowing solutions seem to force OpenGL upon you.

What's the point of supporting DirectX in cross-platform library when DirectX is not cross-platform?

Quote:Original post by swiftcoder
Because many cross-platform games/engines support both OpenGL and DirectX, and having to use a different windowing+input library just for DirectX is a complete pain.

Well, you have a valid point, and I will accept patches on this if someone is interested to do that.

I am personally not interested however, because I'm not going to support both APIs in my project. OpenGL runs fine on Windows, and is performance- and feature-wise on par with DirectX. So, what is the reason for using DirectX for cross-platform project? I see none.

DirectX is only needed when targeting Xbox, and probably in that case PC windowing library will not suite at all (I'm not sure about this, because I've never programmed for Xbox).

Quote:Well, it will not happen at all when using composited desktop (Aero on Windows Vista and Windows 7). And that is what most users will use in the near future.

Yes, and I look forward to the day when we don't have to worry about XP any more :) But, I don't know that we're quite there yet.

Quote:And games usually run fullscreen, so this is not an issue. Windowed mode is useful for development and that single flaw is not so important.

Well, you seem to be making a lot of assumptions about what the end user will or will not want to do. From what I read online I get the impression that quite a lot of folks play games in windowed mode, although I may be wrong about that.

Quote:So, to summarize: I also like aesthetics and polish, but this one just not worth the burden. :)

Obviously others who have implemented similar frameworks have felt the same way, so I guess you're in good company :)