Re: Accessing window back buffer without deprecated functions in Tiger
Re: Accessing window back buffer without deprecated functions in Tiger
- Subject: Re: Accessing window back buffer without deprecated functions in Tiger
- From: Tobias Stamm <email@hidden>
- Date: Thu, 16 Mar 2006 19:44:59 +0100
Thanks,
I think the problem you're going to run up against is resolution-
independence. You can enable this now if you look at all the
options in Quartz Debug. This is supposed to be a feature that end-
users can enable in a future OS release. This will let the user
scale up a window's contents by an arbitrary percentage. So your
"pixel" may actually be 1.3 pixels wide on screen, and straddle
four physical pixels.
One reason for QuickDraw's deprecation was that it couldn't handle
a change like that. It was too bitmap-centric. All of the new
graphics code is vector-based, because it can scale.
This is interesting. Looks like they've made more progress than I
thought. Just starting to discover all the good things of Tiger. Of
course, QD cannot handle this and drawing pixels directly seems to be
deprecated too. I will have to read a little more in the manuals for
really getting the knowledge of using such features (or at least
getting the idea, what it could look like in one of the next
versions...)
To answer your question more directly, if you want to write pixels
to a window, you can use an OpenGL view and render a quad texture.
This would be about as fast as writing pixels directly, and will
scale perfectly (it's just a texture!).
I already wanted to use OpenGL but I never thought about textures.
Hm, I have to find a way of mapping regions of a bigger image to one
texture (I want to create multiple views of the same image, partially
zoomed in). As long as I do not need to update and swap the GL-
Buffers too often, this should not be a problem. Good idea, I will
try to find my way.
Well, ... Why complicated, when there is this great library. But
still, are there other suggestions?
Thanks again,
Tobias
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden