Re: [Tuxpaint-devel] Updated 'rainbow' color picker

[Bill K. <nb...@so...>]

On Sat, Mar 05, 2022 at 12:48:57AM +0100, Pere Pujal i Carabantes wrote:
> Hi,
> 
> El dj. 03 de 03 de 2022 a les 00:09 -0800, en/na Bill Kendrick va escriure:
> 
> > 
> > Please pull from the Git repo and try it out and
> > let me know what you think and (especially) if
> > you notice any issues with it!
> 
> Just tested in the sdl2.0 branch, looks nice :)
> Found some things:
> 
> When you start it with the default values there are 
> a couple of ghost markers at the top left of colors 
> and top of the value box.

Mended.  I'm not actually doing the clipping, but letting
the lack of a wider UpdateRect or Flip prevent the extraneous
bits from appearing on the screen. ;)

I also made the crosshairs bigger, and scale up based on `button_scale`
(a float multiplier based on --buttonsize option).


> When the mouse is over the value box maybe it should 
> have a different cursor, a cross, a hand?

Oops, yep.  Made it a hand.


> When you click and drag in the value box the color 
> doesn't updates until you release, this is different 
> from clicking and dragging in the colored square.

I've implemented this -- a few days ago, actually.

Yesterday, though, I realized that re-rendering the entire Hue/Sat
rainbow rectangle for every mousemotion was very CPU intensive.
In fact, on a larger UI (I tried --1920x960 --buttonsize=128, though
it scales back to buttonsize of ~70), even on my relatively fast &
modern laptop, if I wiggled the mouse around the grey Value slider,
Tux Paint would take a second or two to catch up.

Therefore, every time it re-renders the rainbow (all of the relatively
intensive HSV->RGB floating point math and pixel-putting), it will
spin in a tight while() loop, eating SDL events until it runs out,
or lands on something that isn't a MOTION.  (It then puts the very
last event back into the queue via a PushEvent call.)

Hopefully this works okay.  I'd appreciate it if people could hammer
on the updated UI, and let me know how your systems handle it.
(Pere, I'd especially appreciate testing on a mobile device.
If you want to build a non-release-candidate test version for me
to play with on my phone and maybe some other Androids around my
house, I'd be happy to.)

My main regret is I was up too late fighting with the crosshair code.
(In the end, it's flexible... the size and thickness of the inner
white "+" shape, and the thickness of the black border, are all
variable now!)

Thanks for the feedback!

-- 
-bill!
Sent from my computer