Index:
[thread]
[date]
[subject]
[author]
From: BERNARD Sebastien <sebastien.bernard@cegetel.fr>
To : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
Date: Mon, 17 May 1999 17:25:38 +0200
RE: Some though about raster operation.
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEA079.86FBC580
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> -----Message d'origine-----
> De: becka@rz.uni-duesseldorf.de [SMTP:becka@rz.uni-duesseldorf.de]
> Date: lundi 17 mai 1999 16:56
> =C0: ggi-develop@eskimo.com
> Objet: Re: Some though about raster operation.
>=20
> > IMHO, the ggiCopyBox and ggiCrossBlit are not enough to the high =
level
> > application.
>=20
> Yes. They are not intended for that.
>=20
> > There are some raster operation which are missing (some of them are
> defined
> > in the svgalib.h).
>=20
> Yes. LibGGI2d is intended to be used for higher level needs like =
raster
> operations.
[BERNARD Sebastien] Is libggi2d using lowlevel acceleration ? For
me it is not clear which operator goes to which library. The stubs for =
the
BlitOp are empty. IMHO all the operations that can be accelerated could =
be
in the libggi, and only really high level operation must be in the =
libggi2d.
> > It is worth ? This copybox speeds up copy vertical part of the
> screen
> > (whole width) from one frame to another.
>=20
> I don't think that is a very common operation - is it ?
> We could still do it, but it's probably not worth the bother.
[BERNARD Sebastien] Basically high level operation relies on this.
Think about the game screen which is a little narrower than the screen
itself (because of some information panel), about lazy frame update =
where
you just update from the minimum y to the maximum y modified (should =
be
easy to implement), some double buffering where you copy the whole =
frame
(only one memmove called with this optim) by using the ggiCopyBox to =
stay
high level (but for this one, I think it could be better to do the =
memmove
alone).
> > Could we do some generic subroutine which do basic operations which =
are
> the
> > same from 8 16 24 32 bpp (except for the number of bytes).
>=20
> That is pretty much what the generic stubs do.
[BERNARD Sebastien] No, look at GGI_lin{8,16,24,32}_copybox in the
copybox.c (default/linear_x directory). This is pretty the same but =
for one
constant. Why not using one subroutine instead of 4. The value of the
constant could be deduced from the visual (so the routine is not realy
specific to the display). I think it is not the only subroutine like =
this.
> > Could be done like, generic_ggiCopyBox(*vis, x,y,w,h,nx,ny).
> > The size of the pixels are already stored in the visual, so maybe =
could
> we
> > retrieve this value from the internal and use it to do our =
computations
> ?
>=20
> Why would one want to do so ? If we use it with the sublib stuff we =
have,
> we don't have to care about the size, as we know it due to the fact =
that
> the code has been loaded and is executing.
>=20
> CU, ANdy
>=20
> --=20
> Andreas Beck | Email : <Andreas.Beck@ggi-project.org>
------_=_NextPart_001_01BEA079.86FBC580
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Some though about raster operation.</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Message d'origine-----</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">De: </FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">becka@rz.uni-duesseldorf.de =
[SMTP:becka@rz.uni-duesseldorf.de]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Date: </FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">lundi 17 mai 1999 16:56</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">=C0: </FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">ggi-develop@eskimo.com</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Objet: </FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Re: Some though about raster operation.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> IMHO, the ggiCopyBox and =
ggiCrossBlit are not enough to the high level</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> application.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Yes. They are not intended for =
that.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> There are some raster operation =
which are missing (some of them are defined</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> in the svgalib.h).</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Yes. LibGGI2d is intended to be used =
for higher level needs like raster</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">operations.</FONT>
<BR><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[BERNARD =
Sebastien]</FONT></I></B><I></I> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Is libggi2d using lowlevel acceleration ? For me it is =
not clear which operator goes to which library. The stubs for the =
BlitOp are empty. IMHO all the operations that can be accelerated could =
be in the libggi, and only really high level operation must be in the =
libggi2d.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> It is worth ? This copybox speeds =
up copy vertical part of the screen</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> (whole width) from one frame to =
another.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I don't think that is a very common =
operation - is it ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We could still do it, but it's =
probably not worth the bother.</FONT>
<BR><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[BERNARD =
Sebastien]</FONT></I></B><I></I> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Basically high level operation relies on this. Think =
about the game screen which is a little narrower than the screen itself =
(because of some information panel), about lazy frame update where you =
just update from the minimum y to the maximum y modified (should =
be easy to implement), some double buffering where you copy the whole =
frame (only one memmove called with this optim) by using the ggiCopyBox =
to stay high level (but for this one, I think it could be better to do =
the memmove alone).</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> Could we do some generic =
subroutine which do basic operations which are the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> same from 8 16 24 32 bpp (except =
for the number of bytes).</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">That is pretty much what the generic =
stubs do.</FONT>
<BR><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[BERNARD =
Sebastien]</FONT></I></B><I></I> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> No, look at GGI_lin{8,16,24,32}_copybox in the =
copybox.c (default/linear_x directory). This is pretty the same =
but for one constant. Why not using one subroutine instead of 4. The =
value of the constant could be deduced from the visual (so the routine =
is not realy specific to the display). I think it is not the only =
subroutine like this.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> Could be done like, =
generic_ggiCopyBox(*vis, x,y,w,h,nx,ny).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> The size of the pixels are =
already stored in the visual, so maybe could we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> retrieve this value from the =
internal and use it to do our computations ?</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Why would one want to do so ? If we =
use it with the sublib stuff we have,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">we don't have to care about the size, =
as we know it due to the fact that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the code has been loaded and is =
executing.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">CU, ANdy</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Andreas =
Beck &n=
bsp; | Email : =
<Andreas.Beck@ggi-project.org></FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEA079.86FBC580--
Index:
[thread]
[date]
[subject]
[author]