Fwd: Gradient Framebuffer Fill Bug?

[Ray Strode]

These messages accidentally drifted off list I think.  Forwarding to
the list for those following along...

--Ray


---------- Forwarded message ----------
From: Jonathan Greig <redteam316 at gmail.com>
Date: Mon, Mar 16, 2009 at 8:56 PM
Subject: Re: Gradient Framebuffer Fill Bug?
To: Ray Strode <halfline at gmail.com>


> I think the idea there is so if only a small rectangular part of a big
> full screen gradient gets updated, we can just pass in the x, y, width
> and height of that area and it will just fill in the part of the
> background gradient that needs to get updated.
>
> That's certainly not intuitive behavior though, it seems like it would
> be worth fixing.  Looking at the gradient code, I guess we need to
>
> - compute the steps based on area, not buffer->area.
> - figure out how to make sure the noises generated over multiple runs
> with different x, y, width, height values is generated in the same
> places.  I guess we could pregenerated a noise map or something along
> those lines  instead of depending on the srand() hack that's there
> now.

Yes, please do modify it to work like this. I'm not sure exactly how
the updating works exactly as I took a quick look at the function
itself, and while I understand the color interpolation, there are
still many things I've yet to learn about plymouth. If someone needs a
fullscreen gradient then they would code it fullscreen. Although as I
am quickly learning, on any moving object that needs to update only a
portion of the screen, needs to update the last rectangular area as
well as the new, to avoid the clone/tracer effect. Alpha fading
tracers are cool and could be done, what I am referring to is just a
portion of the screen that is missed updating. I have already toyed
with fullscreen updating but that indeed causes massive flicker and
major lag.
1) Also, Could there be a parameter added so that the gradient can be
horizontal too? I think adding it to the end, with a default of
vertical should not break any previous code that anyone's wrote. As
far as horizontal goes, looping through columns first by knowing the
image width to grab the correct pixels.
2) It would also be nice to see a circular/elliptical gradient added.
Having it use sin() and cos() to determine the radii, then use a loop
to go through 360 degrees, increasing the radii each loop. The main
problem would be determining how to pick up any possibly missed pixels
that may occur inbetween n and n+1 radii. I think for ellipses, that
doing each calculation on the minor axis would probably pick up all of
these pixels, but no way to tell without actually testing it. I think
the logic is sound.
3) Linear gradients at any angle. While this is yet again a little
harder than 0 and 90, would be a nice feature. I think it would be
similar to the elliptical concept above except work by using the angle
to find the tangent/sides of a triangle. Hold the tangent and start
with the shorter leg and find out the farthest pixel on the long leg
based on the tangent. At that point you can put that into a loop that
increases the short leg each loop and recalculates the next line.
4) Square gradients. Similar yet again, although the loop increases a
rectangle each time to achieve the gradient. Probably the easiest to
implement of the ideas suggested here, picking up all pixels should be
fairly straight-forward.
5) Will there be an option to fade to transparent in the future? I
would think this is probably in the works considering most of the
other blitting/framebuffer functions have at_opacity equivalents.

Maybe I can help out with some of these ideas considering I'm familiar
with some of the concepts involved.



> Not sure.  note on_erase can get called for other than full screen
> updates.  that might have something to do with it.  If you reboot does
> the problem go away?
>
> If you file this as a bug report on bugs.freedesktop.org, I can try to
> look into these things, or if you want to figure out what's going on,
> that'd be good too.

I'll take a look into it some more, most likely it's a fault of my
own. Although I do have a question that somewhat pertains to this...
Clipping.
Does plymouth handle clipping anything that it blitted outside of the
screen. I'm asking this as I originally thought the glitch might be
happening because the rectangle may have been 1 pixel-line outside of
the screen.
I did some other tests not using any of the clip framebuffer functions
and intentionally moved the image around the screen so that in some
cases moved completely off of the screen. It did not segfault and I
did not get any weird graphical glitches, so I am guessing at this
point that it is okay to do that, and that the clip functions are
merely for manipulating the type of blit you want to achieve rather
than for safety purposes. I'm curious about this as doing any direct
pixel manipulation outside of a window in SDL is a no-no. I learned
about this before I learned the "Simple" way to do it with the
foolproof functions :)

---------- Forwarded message ----------
From: Ray Strode <halfline at gmail.com>
Date: Tue, Mar 17, 2009 at 11:10 PM
Subject: Re: Gradient Framebuffer Fill Bug?
To: Jonathan Greig <redteam316 at gmail.com>


Hi,

> 1) Also, Could there be a parameter added so that the gradient can be
> horizontal too? I think adding it to the end, with a default of vertical
> should not break any previous code that anyone's wrote. As far as horizontal
> goes, looping through columns first by knowing the image width to grab the
> correct pixels.
Horizontal gradients makes sense, but we'll probably have to fix the
plugins if we change the function name
(which isn't a big deal, the plugin api isn't stable)

> 2) It would also be nice to see a circular/elliptical gradient added. Having
> it use sin() and cos() to determine the radii, then use a loop to go through
> 360 degrees, increasing the radii each loop. The main problem would be
> determining how to pick up any possibly missed pixels that may occur
> inbetween n and n+1 radii. I think for ellipses, that doing each calculation
> on the minor axis would probably pick up all of these pixels, but no way to
> tell without actually testing it. I think the logic is sound.
> 3) Linear gradients at any angle. While this is yet again a little harder
> than 0 and 90, would be a nice feature. I think it would be similar to the
> elliptical concept above except work by using the angle to find the
> tangent/sides of a triangle. Hold the tangent and start with the shorter leg
> and find out the farthest pixel on the long leg based on the tangent. At
> that point you can put that into a loop that increases the short leg each
> loop and recalculates the next line.
> 4) Square gradients. Similar yet again, although the loop increases a
> rectangle each time to achieve the gradient. Probably the easiest to
> implement of the ideas suggested here, picking up all pixels should be
> fairly straight-forward.
Kristian Hoegsberg (the original author of the gradient function) has
some ideas on how to do more general gradients that he mentioned to me
recently.
Could be he'll do it.

> 5) Will there be an option to fade to transparent in the future? I would
> think this is probably in the works considering most of the other
> blitting/framebuffer functions have at_opacity equivalents.
Seems okay to me.  I think the gradient code was originally intended
to be more  "draw a gradient background"  than a "draw a generic
gradient" but having the ability to do more flexible gradients seems
useful.

> Maybe I can help out with some of these ideas considering I'm familiar with
> some of the concepts involved.
Patches welcome of course!

> I'll take a look into it some more, most likely it's a fault of my own.
> Although I do have a question that somewhat pertains to this... Clipping.
> Does plymouth handle clipping anything that it blitted outside of the
> screen.
yes, you'll notice in ply-frame-buffer.c this type of call a lot:

ply_frame_buffer_area_intersect (area, &buffer->area, &cropped_area)

which means "clip the passed in area to be within the frame buffer area"

> I did some other tests not using any of the clip framebuffer functions and
> intentionally moved the image around the screen so that in some cases moved
> completely off of the screen. It did not segfault and I did not get any
> weird graphical glitches, so I am guessing at this point that it is okay to
> do that, and that the clip functions are merely for manipulating the type of
> blit you want to achieve rather than for safety purposes. I'm curious about
> this as doing any direct pixel manipulation outside of a window in SDL is a
> no-no.
Shoud be fine.  Could be bugs, of course, but it's intended to work.

--Ray