Quote:

Opaque window movement is always slow on the current architecutre, because Intuition/Graphics/Layers is not intendend for that.

Of course, and I fully understand that once the graphics subsystems are PPC, it will be much faster. The blue trolls obviously immediately jumped on it and how much faster MorphOS is at these things, but then they never look at these things in perspective

Personally, I think it showed a lot of potential, and I really wish I could have been in Italy to see it for myself.

_________________
Playstation Network ID: xeron6

Rogue wrote:
Quote:

Opaque window movement is always slow on the current architecutre...

And is just a bunch of eye candy as far as I'm concerned.

Great work! It was amazing how fast you ported it from one platform to another even if it was just in pre-alpha state. That proves the HAL design is solid in my book as well as critical drivers (e.g. timer.device). Bravo!

_________________
ExecSG Team Lead

Quote:

Rogue wrote: If you have ever seen the very early GTK ports under Windows, they suffer from a very similar problem.

Speaking of which, are there any plans to include a GTK+ port in a 4.x release?

_________________

by Rogue on 22-Sep-2003 19:01:52

Quote:

Quote: They were talking about window refresh, opaque move/size speed etc., Opaque window movement is always slow on the current architecutre, because Intuition/Graphics/Layers is not intendend for that. Also, Workbench was still 68k on that image (the PPC version popped up a day earlier, but I didn't want to take chances) so its refresh is emulated, too.

hmmm... i've seen those movies and must say that the pure opaque move looks very fast to me. what ctually looks really slow is the redraw of reaction windows. i'm not sure what is displayed on the workbench screen in the movie but i think this are prefs-windows.
and they are slow.

byebye...

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

Quote:

Opaque window movement is always slow on the current architecutre, because Intuition/Graphics/Layers is not intendend for that.

Hmm ... not intended? You just need a "not quite as
bad as original" layers.library (Thomas Richter should
have fixed this) and in graphics.library fast region
functions. YXBanded region algorithms like used by X11 (or
aros thanks to Fabio) might be a must, as they (although
often resulting in regions having more cliprects than really
need to describe a shape) are *much* faster than normal
region algorithms.

Intuition shouldn't actually have much to do with
opaque speed problems at all!? Or maybe you just mean
delayed-app-refresh/lagging-refresh symptoms. If
so opaque moving is likely implemented the wrong way,
by just calling MoveWindow() or so in Intuition's InputHandler.
That's fast but causes problem because input.device
(high pri task Intuition's InputHandler runs under)
can end up eating all cpu time, and poor apps have
no time to do their part of the refreshing. Until user
for a moment pauses moving the mouse -> they can
finally refresh.

A common way to fix this is to *not* call MoveWindow,
SizeWindow in InputHandler, but to send some msg/signal
to a opaque helper task (task pri 0, like other apps) and the
help task will then make the call to MoveWindow/SizeWindow.
This way cpu time no longer goes all to input.device but
apps get a bit of it too, to do their refreshing part.