|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Tue, 9 Jan 1996 19:13:51 -0800 (PST) From: Jonathan Locke <jonl@sealevelsoftware.com> To: Jim Graham <flar@bendenweyr.Eng.Sun.COM> Cc: java-interest@java.Eng.Sun.COM In-Reply-To: <9601100118.AA26981@bendenweyr.Eng.Sun.COM> On Tue, 9 Jan 1996, Jim Graham wrote: > > > 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. sounds good. by "may", i assume you mean "they will be collapsed if possible" > 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? now that i understand the purpose, i can see this is a useful thing. the ImageProducer/ImageConsumer drawing code (i assume that's what you're referring to) is very nice, by the way. you are correct. there is no windows equivalent. you would have to use a timer. (would still be nice to have timer events in java though... creating a thread class just to implement timer functionality is a slight pain) > 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. ok. i don't mind this plan. i still think BitBlt is a more intuitive if you want to Blt a sub-rectangle of a bitmap... but clipping will get the same job done i guess. > 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... i think so too. thankyou! J > > ...jim > - This message was sent to the java-interest mailing list Info: send 'help' to java-interest-request@java.sun.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |