Fabio Alemagna [EMAIL PROTECTED] wrote:
O.K. - seems like we are finally getting somewhere. Thank you for your
patience.
The thing that annoyed me was basically to insist on automatic
backbuffering and that I was in the impression, that you wanted to have it
done synchronously. Now I see quite
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
Not at all! AROS does it, AmigaOS does it, exactly that way! Screens have
buttons on the top right that let them be put to back/front, and
applications NEVER notice it: they continue to run seamlessy and when
their screen is put to front again its
the user pays for console switching on slow machines. The user
doesn't
have to switch, it is a feature.
uhmm... I guess you mean: The user doesn't _need_ to switch... :-)
Jos
--
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
+++ GMX - Mail, Messaging more http://www.gmx.net +++
On Wed, 22 Jan 2003, Christoph Egger wrote:
uhmm... I guess you mean: The user doesn't _need_ to switch... :-)
Amen.
English and early mornings don't go together...
Jos
On Wed, 22 Jan 2003, Christoph Egger wrote:
the user pays for console switching on slow machines. The user
doesn't
have to switch, it is a feature.
uhmm... I guess you mean: The user doesn't _need_ to switch... :-)
Even worse: how the hell do you know the user doesn't need to switch?
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
On Wed, 22 Jan 2003, Jos Hulzink wrote:
Yeah, but if you think well about this, you would see that it doesn't work
in the general case.
Sorry, you're just wrong there: it has worked in the general case for
ages, since AmigaOS was born.
Yeah
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
[...]
You miss, that in X, you never talk to the graphics HW directly. X will
send you an event when you iconify, and will nicely gobble up all
your funny drawing requests if you don't act on it.
Not completely true: if backing store is active
On Tue, 21 Jan 2003, Jos Hulzink wrote:
And, let's face it: For which programs would a background framebuffer be
useful and worth the trouble ? For programs that can't refresh within
#include fuzzylogic.h GGI_SMALL_AMOUNT_OF_TIME.
I'd rather say the impatient user. :-) I really like the
Hi,
Rodolphe, I think you sum things up nicely!
This is simply because there is usually
no MMU-like features (page tables, memory protection) wrt the graphic
board memory; so nearly none of the VM mechanisms used for ...
IMHO, KGI should only worry about managing the features of the
On Wed, 22 Jan 2003, Rodolphe Ortalo wrote:
I just start now in this heated discussion.
Apparently, there are several subjects:
1) Whether generic backbuffering is desirable or not in general;
2) Whether it is possible to implement such a backbuffering mechanisms in
a safe way on current
On Wed, 22 Jan 2003, Rodolphe Ortalo wrote:
On Tue, 21 Jan 2003, Jos Hulzink wrote:
And, let's face it: For which programs would a background framebuffer be
useful and worth the trouble ? For programs that can't refresh within
#include fuzzylogic.h GGI_SMALL_AMOUNT_OF_TIME.
I'd rather
On Wed, 22 Jan 2003, Jos Hulzink wrote:
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
On Wed, 22 Jan 2003, Jos Hulzink wrote:
Yeah, but if you think well about this, you would see that it doesn't work
in the general case.
Sorry, you're just wrong there: it has worked in the general
On Wed, 22 Jan 2003, Rodolphe Ortalo wrote:
And, let's face it: For which programs would a background framebuffer be
useful and worth the trouble ? For programs that can't refresh within
#include fuzzylogic.h GGI_SMALL_AMOUNT_OF_TIME.
I'd rather say the impatient user. :-) I really like
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
[...]
only platform), and also because there exist one free alternative to
AmigaOS, which is AROS, and another commercial alternative which is
MorphOS, and everyone of dem deals perfectly with the issue we're
discussing here. I'll explain in another
On Wed, 22 Jan 2003, Andreas Beck wrote:
Think about something like a PDA. They have buttons to bring specific Apps
to the front. That is pretty similar to a switchaway. Now such a PDA
has no MMU usually ... so how do we transparently remap the VidRAM
to some normal RAM there?
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
uh? Because it's not the same thing and because it's NOT TRANSPARENT! The
whole point of kgi/ggi is that the app doesn't _know_ where it's running,
so tying it with a specific target is the dumbest thing to do.
look there: vtswitch_request. So, does
That's what I am saying. You _have_ to schedule VT-switching. And if you
already have to do that, why not just have the application acknowledge
the request and all is easy and smooth.
uh? Because it's not the same thing and because it's NOT TRANSPARENT!
Why does it have to be? The app
On Tue, 21 Jan 2003, Andreas Beck wrote:
That's what I am saying. You _have_ to schedule VT-switching. And if you
already have to do that, why not just have the application acknowledge
the request and all is easy and smooth.
uh? Because it's not the same thing and because it's NOT
On Tue, 21 Jan 2003, Andreas Beck wrote:
The app has to specify anyway what it wants to do
in case it is switched away.
Yes, and often the app might want to _continue_ working even if it's
switched away.
That's the case, _if_ the application catches the signal.
If the app will just
On Tue, 21 Jan 2003, Christoph Egger wrote:
Yes, and often the app might want to _continue_ working even if it's
switched away.
That's the case, _if_ the application catches the signal.
And that's wrong, imho, because usually apps will want to run in bg, and
thus making that the default
On Tue, 21 Jan 2003, Christoph Egger wrote:
Yes, and often the app might want to _continue_ working even if it's
switched away.
That's the case, _if_ the application catches the signal.
And that's wrong, imho, because usually apps will want to run in bg, and
thus making that the
On Tue, 21 Jan 2003, Christoph Egger wrote:
On Tue, 21 Jan 2003, Christoph Egger wrote:
Yes, and often the app might want to _continue_ working even if it's
switched away.
That's the case, _if_ the application catches the signal.
And that's wrong, imho, because usually apps
Hi,
That's stuff that can be done in the GGI target, which means this is
transparently to the GGI application. :)
Which is what I'm saying: let do it to the kgi target, not to the
application.
That has been the intention the entire time. Nobody expected users to
handle these signals
On Tue, 21 Jan 2003, Brian S. Julin wrote:
Fabio:
I don't understand why applications that want to have a transparent
backbuffer cannot just use display-tile. It is really simple to do,
and target independent. Where is the need for saving the backbuffer
inside the display target itself?
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
AROS could be such an application, for example: it takes advantage of the
X acceleration, and uses the backing store facility of X.
If AROS can use X, it can also redraw its entire screen, because, as
I said before, *no* X server guarantees that
Fabio Alemagna [EMAIL PROTECTED] wrote:
And I advocate that if possible it should be all automated: when
applications run on the X target they don't have to bother with such
things, so why should that bother when they run on console targets? And
what if another tartet comes out which has
On Wed, 22 Jan 2003, Andreas Beck wrote:
Think about something like a PDA. They have buttons to bring specific Apps
to the front. That is pretty similar to a switchaway. Now such a PDA
has no MMU usually ... so how do we transparently remap the VidRAM
to some normal RAM there?
Difficult -
Think about something like a PDA. They have buttons to bring specific Apps
to the front. That is pretty similar to a switchaway. Now such a PDA
has no MMU usually ... so how do we transparently remap the VidRAM
to some normal RAM there?
Difficult - right?
Not at all! AROS does it,
On Mon, 20 Jan 2003, Fabio Alemagna wrote:
On Mon, 20 Jan 2003, Brian S. Julin wrote:
Stupid question from an outsider: couldn't it be possible to make the
application still run by making it use an offscreen buffer while not
visible because of VT switching? It would be really
On Mon, 20 Jan 2003, Fabio Alemagna wrote:
On Mon, 20 Jan 2003, Jos Hulzink wrote:
Why should you backup the whole gfx board's memory? Isn't there any way to
back up only the area actually used by the application?
You know, Amigas deal with full screen graphics and swappable screens
On Tue, 21 Jan 2003, Christoph Egger wrote:
How about using the memory target within libggi's kgi-target, when the
application runs in background?
This background mode can be done by copying first waiting until the accel
is idle, then copying the framebuffer content into the userspace memory
On Tue, 21 Jan 2003, Christoph Egger wrote:
How about using the memory target within libggi's kgi-target, when the
application runs in background?
That's basically what I mean.
[...]
The big question is, if this will still work, once libggiovl becomes useable
and the GGI apps requests
On Tue, 21 Jan 2003, Christoph Egger wrote:
How about using the memory target within libggi's kgi-target, when the
application runs in background?
That's basically what I mean.
Then you were not precisely enough. By using the word offscreen, every-
body thought, you mean an offscreen area
Hi,
On Mon, 20 Jan 2003, Jos Hulzink wrote:
On Mon, 20 Jan 2003, Fabio Alemagna wrote:
On Mon, 20 Jan 2003, Brian S. Julin wrote:
Stupid question from an outsider: couldn't it be possible to make the
application still run by making it use an offscreen buffer while not
visible
On Tue, 21 Jan 2003, Christoph Egger wrote:
On Tue, 21 Jan 2003, Christoph Egger wrote:
How about using the memory target within libggi's kgi-target, when the
application runs in background?
That's basically what I mean.
Then you were not precisely enough. By using the word
On Tue, 21 Jan 2003, Christoph Egger wrote:
Why not? If there's enough space in the gfx board memory then the
offscreen buffer should be allocated there.
If you mean both, then please say that... :-)
Well, offscreen to me just means non visible but still available, so it
didn't matter to me
Fabio Alemagna [EMAIL PROTECTED] wrote:
Stupid question from an outsider: couldn't it be possible to make the
application still run by making it use an offscreen buffer while not
visible because of VT switching? It would be really annoying, imho, if
the application stopped altogether...
Been
On Tue, 21 Jan 2003, Andreas Beck wrote:
Why not? If there's enough space in the gfx board memory then the
offscreen buffer should be allocated there.
And not be available for another application I start on the switched to
console?
Why not? Just make the bg app go back to use its own
On Tue, 21 Jan 2003, Andreas Beck wrote:
Fabio Alemagna [EMAIL PROTECTED] wrote:
Stupid question from an outsider: couldn't it be possible to make the
application still run by making it use an offscreen buffer while not
visible because of VT switching? It would be really annoying, imho,
Why not? If there's enough space in the gfx board memory then the
offscreen buffer should be allocated there.
And not be available for another application I start on the switched to
console?
Why not? Just make the bg app go back to use its own offscreen buffer
That requires
Been there, done that. Annoying.
What exactly is annoying?
See below.
The Hardware has quite some state, and not all of it can be retirieved
easily. Thus basically IMHO we will have to face the fact, that the
application will have to cooperate a little when switching away.
If Amigas
My general feelings towards the prospect of keeping tasks drawing in
the background, whether on memvisuals or in VRAM, is that it would be
a very nice feature but it would also be an incredibly hard and time
consuming thing to implement.
The challenges, most already noted by others in this
On Mon, 20 Jan 2003, Filip Spacek wrote:
On Tue, 21 Jan 2003, Andreas Beck wrote:
Bottom line:
Yes, it should be possible for an application to save its screen contents
on switchaway. However I do not recommend to try to outsmart the application
and do that behind its back. Tell
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
C'mon, guys, it's not about outsmarting applications, other OS's can do
it pretty well.
Other OSes don't allow different applications to run in different video
modes. X doesn't either.
--
Brian
On Tue, 21 Jan 2003, Andreas Beck wrote:
Why not? If there's enough space in the gfx board memory then the
offscreen buffer should be allocated there.
And not be available for another application I start on the switched to
console?
Why not? Just make the bg app go back to use its
On Mon, 20 Jan 2003, Brian S. Julin wrote:
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
C'mon, guys, it's not about outsmarting applications, other OS's can do
it pretty well.
Other OSes don't allow different applications to run in different video
modes.
Really? What about AROS and
On Tue, 21 Jan 2003, Andreas Beck wrote:
The Hardware has quite some state, and not all of it can be retirieved
easily. Thus basically IMHO we will have to face the fact, that the
application will have to cooperate a little when switching away.
If Amigas can do it,
Amigas have a very
O.K. - last one for today.
Windows cannot. Look at any semi-crashed application (i.e. one in an
endless loop) there. If it does not redraw a window on its own anymore,
it will not revert to the previos state when you move something over it.
What has that to do with the matter we're
Fabio Alemagna [EMAIL PROTECTED] wrote:
Not necessarily, it just requires a way to centralize memory allocations.
You are only talking about memory. I have already shown that and how it can
be done.
How do you handle half-done accelerator commands? I have not yet heard a
convincing way to
On Sun, 19 Jan 2003, Jos Hulzink wrote:
Hi,
KGI used to set a task to sleep when it was mapped away from a display.
This didn't work always, and with some help from #kernelnewbies, I came to
the conclusion that it isn't even what you want.
A task doesn't need to sleep, it only has to stop
On Sun, 19 Jan 2003, Christoph Egger wrote:
On Sun, 19 Jan 2003, Jos Hulzink wrote:
Hi,
KGI used to set a task to sleep when it was mapped away from a display.
This didn't work always, and with some help from #kernelnewbies, I came to
the conclusion that it isn't even what you want.
51 matches
Mail list logo
