Re: window rotation
Re: window rotation
- Subject: Re: window rotation
- From: Brent Gulanowski <email@hidden>
- Date: Sun, 16 May 2004 10:22:03 -0400
You are over-thinking the problem.
It is not necessary to rotate the window, only the image of the window.
Proposed solution:
1. Keep real window off screen at known co-ordinates.
2. Capture image of real window.
3. Create new, transparent window.
4. Draw image of working window in transparent window.
Render-to-texture OpenGL might be nice for this, if you can locate the
source window's bits.
5. Rotate image as desired.
6. Capture all mouse events of import in transparent window.
7. Un-rotate and translate them and insert them into the responder
chain of the real window.
8. Update image in rotated window.
Trying to maintain an individual transform for each and every window is
crazy. Just have a local and global co-ordinate system and transform
between them.
On May 14, 2004, at 10:12 PM, Wade Tregaskis wrote:
>
In an effort to avoid actual real work, I set about trying to perform
>
the actual graphical rotation of a window. And I've come up at a
>
loss. The best I can manage is to rotate the entire contents of the
>
window, but in a gross way - the bitmaps that make up all the standard
>
controls remain axis aligned, and consequently you get this weird
>
segmented, pseudo-rotated effect. Text rotates fine, of course, but
>
that's about it. There's also a lot of redrawing problems where
>
certain controls obviously use shortcuts or improper methods to
>
determine dirty rects, and consequently miss bits on the rotate
>
version.
>
>
There's also the problem that the window's clipping area remains
>
unchanged, so bits of it's contents which rotate out of it become
>
inaccessible.
>
>
It looks to me like the full-window deformation needs to be done by
>
the window server, not within the end application. There is an
>
unofficial category on NSWindow in AppKit which offers the ability to
>
scale the window - presumably for use by Expose - but in my testing
>
any actual scaling (i.e. scale value <> 1) results in a BAD_ACCESS
>
crash when the window next tries to redraw; it looks like an internal
>
buffer is being destroyed by the scaling [and not recreated], so the
>
normal display code is tripping up when trying to use it. I tried a
>
few obvious attempts to get around this (i.e. instructing the window
>
to clear it's buffers, turning off caching, etc) but without success.
>
>
So, I've been trudging around AppKit for a few hours looking for ways
>
to access "the display server", knowing nothing about it or how it
>
works (i.e. the IPC mechanisms involved, if any). Does anyone know
>
anything about this? It seems (from the scaling example) that,
>
ignoring the crashing bug, it's trivial to adjust the display matrix
>
for the window. The problem is that, aside from the unofficial
>
scaling methods, there's no way to even read the current matrix, let
>
alone change it.
>
>
The conclusion being that, unless I'm missing something obvious, the
>
entire discussion of whether mouse events are properly translated is
>
mute, given the graphical translation can't be performed anyway.
>
>
Wade Tregaskis (aim: wadetregaskis)
>
-- Sed quis custodiet ipsos custodes?
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
>
>
--
Brent Gulanowski email@hidden
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.