Posted by
Michael Bien on
Mar 20, 2011; 8:03pm
URL: https://forum.jogamp.org/Why-CLEventList-has-fixed-size-tp2705613p2706993.html
Hello,
its because of the performance. The list uses a direct allocated
bytebuffer as event id storage. I thought about that already but decided
to go the 100% transparent route (regarding behind the scenes buffer
allocation, synchronization etc) for all runtime APIs.
If it would be a plain old long array i would make it simply expandable...
However what we could do is to add a
CLEventList.create(CachedBufferFactory factory, boolean expandable)
constructor to it. Every expand operation would trigger a copy from the
old buffer to a new buffer, shrinking the list could be difficult to
implement.
Do you think the current static allocation leads to bad code style? How
hard is it for you in your application to predict the event list size?
thank you very much for the feedback
best regards,
michael
On 03/20/2011 11:08 AM, Wibowit [via jogamp] wrote:
> Hi Michael,
>
> I wonder why you've opted for fixed size CLEventList? It brings a lot of
> disadvantages. Why didn't you just extend List and add some implementation
> specific functions?
>
> I could write a wrapper event list and wrappers for functions requiring
> CLEventList but that would be a unnecessary bloat.
>
> Is there a chance for a normal, dynamically-sized collection?
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
>
http://forum.jogamp.org/Why-CLEventList-has-fixed-size-tp2705613p2705613.html> To start a new topic under jogamp, email
[hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/