[Top][All Lists]

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

[Octave-bug-tracker] [bug #42561] gnuplot colors incorrect for 'demo tri

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #42561] gnuplot colors incorrect for 'demo trimesh'
Date: Thu, 8 Sep 2016 05:51:33 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Follow-up Comment #11, bug #42561 (project octave):

This bug has come to my attention.  There's been a temporary fix for the
gnuplot errors by forcing color values to be uint8 between 0 and 255.


Obviously the colors come out incorrect, and I think it is just a matter of
mapping the color values to the proper range.  We've done some other types of
mapping based on cmap and that sort of thing elsewhere.

I'd like to first ask a more general question about how this scatter plot sets
up data.  I'm a bit surprised that markers go through the "patch" route.  I

[break after the second demo with filled circles]
kids = get(gca,'children')
grandkids = get(kids, 'children')
get(grandkids (1))

and these items all have 'tag' property 'patch'.  Is __scatter__.m choosing to
do this because it is the only way for markers to have colors different for
each marker?  (gnuplot can handle plotting markers as a function of color.) 
The ramification of this is that scatter.m seems to be a very slow routine,
regardless of toolkit, when all it is doing essentially is plotting a
collection of markers.  (My guess is that there is some slowness associated
with constructing all the plot elements and properties...is this an internal C
routine or done as a script?)  I'm just trying to think if there is a way to
speed things with a change in organization before altering the patch sub-code.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]