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:45:58 +0200

Some precision about raster operation (Was RE: some though about raster operations)

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_01BEA07C.5DDD3F50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Let me explain my problems.
It tried to use the freetype engine for displaying fonts on a =
ggi-target (oh
surprise!!!).
This engine is really low-level, so you have to pass him either a =
bitmap (a
memory target 1pixel deep) or
a pixmap (memory target 8 pixel deep) with 5 gray level defined for
anti-aliasing calculations.
So, to display a pixel, you have to setup the pixmap, clear it, let the
engine render into it (8 bit/pixel) then crossBlit the result from the
memory target to the screen.
But, when doing crossBlit, it overwrites the background (which was =
cleared).
The engine is OK, it can deal with then background, then I have to copy =
from
the screen the backgroup to the memory.
So I have maybe to setup more colors to match all the colors I used in =
the
backgrond (I'm using 32bit-depth plan) must
may not fit into the memory target - which is only 8bit paletted-.
What next, the best would have been a crossBlitOp(with a or).
Problem, this doesn't exist in the libggi, only in the libggi2d which =
is
incomplete (the stub function is empty).
According to me, the blitOp belongs to the libggi (same as crossBlit =
but
instead of doing dst =3D src, do dst =3D funct(src,dst) - or better dst =
=3D
funct(src, dst, msk) ). I was thinking about the bitblt function of the
Atari ST for the old folks.
Another thing I can do, is to get a direct buffer, and write my blitOp =
for
every kind of possible target.

> -----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.
>=20
> > 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.
>=20
> > 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.
>=20
> > 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_01BEA07C.5DDD3F50
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>Some precision about raster operation (Was RE: some though about =
raster operations)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Let me explain my =
problems.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It tried to use the =
freetype engine for displaying fonts on a ggi-target (oh =
surprise!!!).</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This engine is =
really low-level, so you have to pass him either a bitmap (a memory =
target 1pixel deep) or</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a pixmap (memory =
target 8 pixel deep) with 5 gray level defined for anti-aliasing =
calculations.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So, to display a =
pixel, you have to setup the pixmap, clear it, let the engine render =
into it (8 bit/pixel) then crossBlit the result from the memory target =
to the screen.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But, when doing =
crossBlit, it overwrites the background (which was cleared).</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The engine is OK, =
it can deal with then background, then I have to copy from the screen =
the backgroup to the memory.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So I have maybe to =
setup more colors to match all the colors I used in the backgrond (I'm =
using 32bit-depth plan) must</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">may not fit into =
the memory target - which is only 8bit paletted-.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">What next, the best =
would have been a crossBlitOp(with a or).</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Problem, this =
doesn't exist in the libggi, only in the libggi2d which is incomplete =
(the stub function is empty).</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">According to me, =
the blitOp belongs to the libggi (same as crossBlit but instead of =
doing dst =3D src, do dst =3D funct(src,dst) - or better dst =3D =
funct(src, dst, msk) ). I was thinking about the bitblt function of the =
Atari ST for the old folks.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Another thing I can =
do, is to get a direct buffer, and write my blitOp for every kind of =
possible target.</FONT>
</P>
<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>
</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>
</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>
</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_01BEA07C.5DDD3F50--

Index: [thread] [date] [subject] [author]