On Fri, 27 Apr 2012 12:16:46 -0400, Rene Zwanenburg
wrote:
I've run a few times in the 'dtor allocating memory' problem, but it's
usually easy enough to work around. One more question: Is that a
limitation of the current GC implementation, or something intrinsic to
garbage collection in
On Fri, 27 Apr 2012 17:55:02 +0200, Rene Zwanenburg
wrote:
I _could_ modify the system to use ref counting everywhere, but I'm
reluctant to do that.
You wouldn't really need to. Only the texture struct would need that.
Look to std.typecons's RefCounted[1] for inspiration. One could easily
i
On Friday, 27 April 2012 at 15:59:50 UTC, Steven Schveighoffer
wrote:
On Fri, 27 Apr 2012 11:55:02 -0400, Rene Zwanenburg
wrote:
Which reminds me, does the GC actually block all threads while
calling the destructors on garbage? I'm far from an expert on
GC's, but I believe the mark needs to
On Fri, 27 Apr 2012 11:55:02 -0400, Rene Zwanenburg
wrote:
Which reminds me, does the GC actually block all threads while calling
the destructors on garbage? I'm far from an expert on GC's, but I
believe the mark needs to stop the world, but the sweep can be done
concurrently. If the GC
On Friday, 27 April 2012 at 13:04:32 UTC, Dmitry Olshansky wrote:
Don't. If I still worth anything in GL texture is bound to an
opaque uint of sorts. There is no problem copying this number
around.
There is no point in holding multiple references to 42 ;) Just
copy the number.
That's correct.
On Friday, 27 April 2012 at 13:13:20 UTC, Steven Schveighoffer
wrote:
Yes it's hard. The GC has no access to compile-time type
information. It relies on runtime information. The GC is able
to call the dtor for classes because classes store a pointer to
their typeinfo in the class instance it
On Fri, 27 Apr 2012 14:57:52 +0200, Rene Zwanenburg
wrote:
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
On Fri, 27 Apr 2012 08:57:52 -0400, Rene Zwanenburg
wrote:
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
On 27.04.2012 16:54, Rene Zwanenburg wrote:
[snip]
True, but what would using structs do to fix the problem?
The reason I'm using (final) classes is because a resource can be used
by multiple objects. If two meshes use the same texture, I don't want to
load that texture twice.
Don't. If I sti
On Friday, 27 April 2012 at 12:03:18 UTC, Dmitry Olshansky wrote:
Boom! Just LOL...
Use manual memory management or ref-counting. If
std.container.Array was not so bogus I'd recommend it for
arrays.
Yeah, I already have a few different types of smart pointer which
can work with custom alloc
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
calls made
from other threads will fail. I've wrapped OpenGL 'obj
On Friday, 27 April 2012 at 11:23:06 UTC, Dmitry Olshansky wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
calls made
from other threads will fail. I've wrapped OpenGL 'objects' in
D classes
to automate destruction of the underlying
On 27.04.2012 15:53, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to automate destruction of the underlying obj
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to automate destruction of the underlying object:
How about using structs for GL objects? It's not like you h
15 matches
Mail list logo
