[4637] in java-interest
Re: missing functionality : drawImage != BitBlt/StretchBlt
daemon@ATHENA.MIT.EDU (Jim Graham)
Tue Jan 9 21:50:35 1996
Date: Tue, 9 Jan 1996 17:18:38 -0800
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
To: jonl@sealevelsoftware.com
Cc: java-interest@java.Eng.Sun.COM
> not much to go on, if you ask me. if i call repaint 10,000 times in one
> second do i get 10,000 calls to update?
Not necessarily. update() callbacks may be collapsed by the implementation.
> that's why i gave up on
> this function early on... it doesn't look like it does an InvalidateRect.
> so what exactly does it do? i tried using it and it seems to work fine
> for my classes.
I'm not sure what distinction you are making, but it performs the same
job as InvalidateRect as far as I understand the two. Both eventually
result in some form of callback in which you are supposed to redraw the
indicated region.
> the other thing that really bothered me was... what's
> this whole thing about ensuring an update within X milliseconds?
> there should be some indication of why this is useful and how the
> underlying mechanism works... we don't have this feature in Windows...
> and to be honest, i can't see immediately why anyone would need it.
If you know that a particular region has new data, but that you might
get even newer data soon, the timeout argument provides a way to throttle
the updates by scheduling them in the future. The part of your application
or applet that is responsible for receiving new data and incorporating it
into your internal state can then be independent of the part of your code
that is responsible for redrawing it. The "data integrator" part simply
uses a timeout in its repaint call that represents the maximum refresh
rate that you believe is practical to maintain and the system will collapse
the update callbacks as appropriate. As a result, you will end up repainting
with the new changes within a specified amount of time after receiving them
but you won't constantly be redrawing everything for each and every change
in those situations where they come in faster than is reasonable to do the
repaints...
The incremental image drawing code uses this feature to redraw the
images when new data comes in without redrawing faster than a maximum
update rate. I suppose in Windows the client would have to maintain
its own throttling mechanism to prevent over-frequent repaints?
> > Use clipping to restrict the drawImage to only the rectangle you want.
>
> there is still a need for BitBlt/StretchBlt in any serious GUI environment.
the particular feature of bitblt that you mention is simply an
optimization. It duplicates the effect of setting a clip rectangle.
The plan is that we will do enough optimization of creating and
disposing clipped graphics objects that it will be just as cheap as
doing another version of the drawImage method with even more
arguments. And I agree that our current image scaling infrastructure
is much more wasteful than an on-the-fly StretchBlt function, but
clipped drawImage versus sub-regioned BitBlt should be fairly close.
> someone else pointed out that i
> could use a CropImageFilter or something. maybe that is the equivalent of
> BitBlt in some elegant sort of way... but it's an inefficient solution
> (in any language) and i think it's non-intuitive.
CropImageFilter is there for constructing an image that will be used
repeatedly and frequently and which is a subset of some other image.
Doing a drawImage with clipping is more for a one-shot "I only want to
draw this particular portion - for now" type of situation.
> yes. this seems to work marvelously! but i'm still bothered by not
> really understanding how it is that repaint winds up calling update.
> thankyou for your help.
It is really no different than the way that a call to InvalidateRect in
Windows results in your window receiving WM_ERASEBKGND and WM_NCPAINT
messages. You don't really need to know the details of how in order to
use it for most cases, but better documentation on the specifics of
what you can and cannot rely on would help some programmers who are
depending on the fringe of its behavior...
...jim
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
