Copy-Paste typos in MTLRenderQueue.java comments and javadoc
Jayathirth D v
JAYATHIRTH.D.V at ORACLE.COM
Tue May 19 04:35:21 UTC 2020
Hi Scott,
Yes these things have come from the time when we stared with stub implementation.
I have raised https://bugs.openjdk.java.net/browse/JDK-8245256 <https://bugs.openjdk.java.net/browse/JDK-8245256> for cleanup.
Thanks for the inputs.
Regards,
Jay
> On 18-May-2020, at 9:59 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>
> Just noticed this while poking around. There are a few reference to “OGL” and OpenGL…
>
> /**
> * OGL-specific implementation of RenderQueue. This class provides a
> * single (daemon) thread that is responsible for periodically flushing
> * the queue, thus ensuring that only one thread communicates with the native
> * OpenGL libraries for the entire process.
> */
> public class MTLRenderQueue extends RenderQueue {
>
> ...
>
> /**
> * Flushes the single MTLRenderQueue instance synchronously. If an
> * MTLRenderQueue has not yet been instantiated, this method is a no-op.
> * This method is useful in the case of Toolkit.sync(), in which we want
> * to flush the OGL pipeline, but only if the OGL pipeline is currently
> * enabled. Since this class has few external dependencies, callers need
> * not be concerned that calling this method will trigger initialization
> * of the OGL pipeline and related classes.
> */
> public static void sync() {
>
> …
>
> /**
> * Returns true if the current thread is the OGL QueueFlusher thread.
> */
> public static boolean isQueueFlusherThread() {
> return (Thread.currentThread() == getInstance().flusher.thread);
> }
>
> Should be *MTL* QueueFlusher thread, right?
>
> Regards,
>
> Scott
More information about the lanai-dev
mailing list