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