[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Buffer canvas and transparent background

> On Sun, 2006-04-02 at 10:27 +0900, Carsten Haitzler wrote:
> > how are you using it? using ecore_evas? are you using the update
> > region callback by hand (not ecore_evas) ? i am looking at the
> > code here - if u ask for EVAS_ENGINE_BUFFER_DEPTH_ARGB32 depth -
> > it will zero out the alpha channel every render update - but ONLY
> > the regions rendered to. it won't do it on startup though. so that
> > might be your problem as those regions never get objects and never
> > get a render update as you manually manage your canvas and damage
> > regions (you don't send an initial one)
> I'm not using ecore.  The problem areas are those where evas _has_
> rendered objects before.
> There definitely is a problem.  I spent a while trying to make a
> test case and was unsuccessful until I discovered the problem only
> occurs when the viewport is defined as a size larger than the output
> size.  See the attached test case.  It creates a 640x480 buffer
> canvas and sets the viewport to 800x600.  It creates a 50px high
> rectangle at (0,300) and samples an alpha pixel at the corresponding
> point in the buffer.  It then moves that rectangle to (0,0) and
> samples the alpha at the same spot.  It _should_ be zero, but when
> (and cvs, and possibly earlier versions) the value is
> unchanged.
> Output with cvs from 2006-04-01:
>         Should be non-zero: 94
>         Update: 0,0 560x40
>         Update: 0,240 560x40
>         Should be zero: 94
> Output with cvs from 2005-12-18:
>         Should be non-zero: 155
>         Update: 0,0 560x40
>         Update: 0,240 560x40
>         Should be zero: 0
> Note also the alpha value is different between the two cvs versions.
> I am calling evas_object_color_set(rect, 255, 55, 155, 155) so I do
> expect the alpha value to be 155 there.  cvs-2005-12-18 has correct
> behavior in both cases, whereas 2006-04-01 shows an unexpected alpha
> value, and, more importantly, it's leaving cruft behind when I move
> the object. 
> If the viewport size matches the output size or is smaller then it
> seems to be fine.  It's only when the viewport is larger than the
> output size. 
> Hopefully this helps narrow down the problem.  See attached.

	The relationship between 'canvas' coordinates and viewport
coords vs output size is simple, but one has to be careful.

	The api functions:
 "evas_coord_world_*_to_screen" and "evas_coord_screen_*_to_world"
should be used for converting between canvas coords and viewport

	In your example, you have an output size of (640, 480), and
a viewport at (0,0) of size (800, 600).
	You then create a rectangle object of *canvas* coordinate
size (700, 50) and move it to the *canvas* position (0, 300).

	This means that in *output* coordinates, your rectangle will
be of *output* size (560, 40) and its top-left at *output* position
(0, 240).
	At the output position of (0, 300) there is NO rectangle since
your rectangle begins at output y-pos of y = 240, and ends at output
y-pos of y = (240 + 40).

	As Carsten mentioned, evas won't 'zero' the canvas by default.
	Thus, since you did not specify any values for the canvas as
a whole, the color at x = 0, y = 300, will be junk.
	Moving the rectangle to (0,0) will still not give anything
meaningful at (0,300) since nothing was ever drawn there, and thus
nothing was cleared there.