Hello, > Since most applications do render from one thread (either the > Event Queue like Swing apps, or some kind of dedicated rendering > thread like games), the lock is indeed very fast, given > biased locking and such. > > I would suggest not trying to optimize things - especially tricky > ones which involve locking - until you have > identified with some kind of tool that there's a problem.
I did some benchmarking to find out the best design for my new pipeline, and these are the results I got: 10mio solid 1x1 rect, VolatileImage, server-compiler, Core2Duo-2ghz, Intel-945GM, Linux: 200ms no locking, no native call 650ms locking only 850ms native call, no locking 1350ms as currently implemented in X11Renderer I did rendering only from a single thread (however not the EDT), in this simple pipeline-overhead test the locking itself is almost as expensive as the "real" work (=native call), and far more expensive than an "empty" JNI call. However this was on a dual-core machine, on my single-core amd64 machine locking has much less influence. As far as I know biased locking is only implemented for monitors. Xorg ran on my 2nd core, and kept it with locking only 40% busy, without locking about 80%. However I have to admit there are probably much more important things to do than playing with things like that ;) > If it appears null during a sync() call, no harm is done (the > sync is just ignored - which is fine given that the render queue > hasn't been created yet, so there's nothing to sync), so this is > not a problem. But what does happen if it has already been created, but the thread calling sync() just does not see the updated "theInstance" value? Could there be any problem when sync()-calls are left out? lg Clemens
