Hi Colin,
Thanks for the response. Yeah, my actual data isn't random so I will be
able to define bounds to speed everything up, but random is kind of
worse case scenario. My actual points are defined by a cubic curve so I
don't think I can get around pre-processing them. I guess maybe my
method is the most efficient and once I can limit the data to a 'real
world' scenario then maybe it will be usable. I'm just aware that this
is just the premise at its most basic, I'm going to have to do a lot
more than fill a pixel by the end!
Cheers,
Steve
Colin Doncaster wrote:
If you're keen on using stl containers you can always sort them and
then use lower_bound/upper_bound to define an iterator for the
scanline you're interested in - the sort should be faster than
iterating through the vector for every scanline. The other option is
to store the pixels in a multimap with the key being you're x value
and then "finding" all of the entries with that key value - stl uses
slow hashing for maps though, so on second thought - option 1 might be
best.
I imagine you're reading from disk and/or generating the random points
else where - but an even better option could be removing your
"intermediate buffer" that's holding all the random points and just
setting the pixel value directly from the random number generator? If
you're reading from a file could the random points be sorted prior to
being written thus removing the need all together? Just a shot in the
dark but sometimes the best way of optimizing something is completely
removing it from the equation. :)
Cheers
*/
*/
*/--
Colin Doncaster/*
*/
*/
*/Peregrine Labs/*
/*
/*
*/
*/
www.peregrinelabs.com <http://www.peregrinelabs.com>
/*
/*
/*
/*
On 2011-03-09, at 5:40 AM, Stephen Newbold wrote:
Hi,
I have a question about the best way of 'drawing' a set of
pre-defined points with the NDK. As a simplified example, say I have
a list/vector full of random points (x,y screen coords) where I could
have multiple points on a row in various x positions. I simply want
to draw a pixel for each of these points. Since the draw engine can
call any row in any order, it seems like I have to use a seemingly
inefficient method to check whether the current row/pixel matches one
of the points within my list.
Although I still have to try this, the best I can think of is for
each row called we check to see if the row position (Y) matches that
of any of the y-coords within my list. If not it looks at different
row. If there is a match then we iterate through the points and
output a pixel for every occasion where our X Y matches the coords of
the point. It seems like a lot of work to output pixels for points
we already know the position of and I guess could be very slow if we
have thousands of points. Am I missing something obvious?
Cheer,
Steve
--
Stephen Newbold
Senior Compositor - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com <http://www.moving-picture.com>
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
------------------------------------------------------------------------
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
--
Stephen Newbold
Senior Compositor - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
