jGL for SWT

[jzy3d]

As discussed here, we are willing to make jGL rendering for SWT

Project Layout

• jzy3d-jGL-core
• jzy3d-jGL-awt
• jzy3d-jGL-swt
• jzy3d-jGL-.... (what ever will be cool in the future)

GLCanvas then might be an abstract class with glFlush() the responsibility of the actual AWTGLCanvas / SWTGLCanvas/ ...GLCanvas

GL / GLUT would need, for each windowing toolkit

• implementing GL.glFlush()
• implementing GL.glXSwapBuffer( ... )
• implementing GLUT.processComponentEvent to deal with SWT events

Side discussions

Fonts

Jzy3D IPainter.Font will be refactored to a standalone class trying to carry the same properties than java.awt.Font (e.g. adding style to allow bold/underline etc). It will be used for configuring TextRenderers (TextBitmapRenderer, JOGLTextRenderer). jGL-awt will allow reusing such font properties. Suggestions on SWT font properties to support are welcome. In case underline/italic/bold are carried by int values different from AWT, then a Style enum for such generic core font would be useful.

This Font class is here to allow :

• Best effort for font usage in Jzy3D : if a font query is not supported by the current TextRenderer, then alternative/default font should be provided (TextBitmapRenderer supports two fonts with three size, JOGLTextRenderer supports fonts defined by java.awt.Font)
• Capacity for providing bigger() or smaller() version of themselves to scale the text according to current pixel scale. HiDPI rendering makes static text small and such API is proposed to adapt text to HiDPI or not.

[laeubi]

For SWT in general I thin the FAQ gives a good insigth about common questions of newcommers.

About the threading I'm not aware of a "normative" document but its not very special here, if you know AWT you'll find many concepts in common. The basics boil down to the following (see the HelloWorldSnippet):

• There is a "Display" that is similar to the AWT EventQueue where you can sync/async execute call with a so called "Main Thread" that maps to the EDT in AWT
• The Thread that creates the Display becomes the "Main Thread" and is responsible to dispatch events in a while loop with polling
• Then one might want to open one or more "Shells" (that maps basically to Frame in AWT) that shows the actual UI elements.
  If you like to play a bit with painting stuff the "Canvas Snippet" might be a good starting point.

The main difference to AWT is that SWT has a policy that each public method of a widget checks that the current thread is the Main-Thread and throws an exception otherwise. This ensures that all UI work always happens in the Main/UI Thread.

Even though some OS (mainly windows) support to create more than one Display (and thus might have two or more "Main Threads") thats a very rare use-case and is not platform dependent. This is also reflected by the fact, that the Display has a static accessor Display.getDefault() that allows "non-ui-code" to enter the UI-execution this is similar to EventQueue.invokeLater().

If code is running in the Main thread it should of course leave it ASAP (as no async event processing happens), or must take actions to dispatch the events itself but that's rarely required (mainly to implement blocking dialog calls for example).

I think that it what is relevant for the usecase here in essence.

[laeubi]

Here you find an example where a BufferedImage is converted into an SWT ImageData (that could then be used to draw an Image to the GC (SWTs equivalent to Graphics2D)).
As there is only the raw pixels array extracted from the BufferedImage should work similar here, even though there are room for optimization a first step could be GlBuffer > ImageData > Image > GC

[laeubi]

SWT Fonts supports one "System font" and one can create fonts by name. A font can be Bold/Italic underline could be emulated by drawing a line I think more advanced formatting can be done with https://www.eclipse.org/articles/StyledText%201/article1.html

[jzy3d]

Thank you. I just want to warn you that jGL is changing a bit. I recently added the ability to rotate texts.

[jzy3d]

@laeubi I just made the 2.0.0 release version. This will probably be helpful to you as the master branch was changing a lot in the previous weeks.

[laeubi]

Thanks for the hint, I hope to get some time starting to work in this in the coming weeks.

[laeubi]

@jzy3d I'm looking closer at the code and have noticed that GLUT class refer a AWT Component (but uses reflection to call this) do you think it makes sense to change Component here to a generic Object?
Or should one assume that each implementation (SWT, AWT, JavaFX, ...) might have its own specific GLUT class?

[laeubi]

I have now extracted the AWT part see laeubi@bb82d70 into an own package so the GL class (the actual rendering) is AWT free, I'll now migrate my SWTGL from the example into an swt package as well as a starting point.

@jzy3d can you tell what is required to integrate this with the charting? do we need the GLU/GLUT parts? I can try to extract these also into more generic parts that can be shared but I'm not sure if it is required or if the code there is better implemented in the chart mapping?

[laeubi]

I was now able to produce some image output using the bezcurve example! That's amazing as in general I didn't seem to need any AWT specific classes directly (don't checked the jgl internals) and could copy the pixel buffer relative straigth away!

[laeubi]

See laeubi@9cc9b2d for a minimal runnable example, ther will be much more aspects to solve I think but as a first start is shows how jgl + swt could be integrated

[laeubi]

@jzy3d what do you think about my proposed changes?

[jzy3d]

Hi @laeubi , I just see your message now, I had no notification about it, sorry. I'll try to look at your branch this week.

[laeubi]

Great! Let me know how we can proceed here, I can try to create a PR if its clear how we want to go a haed.

[jzy3d]

Hi @laeubi , sorry again, I discovered my mailer considered this discussion as a spam. Fixed hopefully.

Your code is very clean and readable, thank you for making the clean commits.

Creating the PR is ideal for me because it provides review and discussion. My main point will be to verify it works on my computer as well, besides that your work seams perfect.

I would favor fast merge - there are already some changes since you open the branch. Some improve how jGL is used by Jzy3D so it's better to have them. I haven't made huge changes that would cause conflicts, and may assist you if needed.

[jzy3d]

Hi,
Few things I see that would be easier to discuss on a PR

• There remain build errors in the original emul-gl project that refer to the former GLCanvas now in jgl.awt
• I would bundle packages .awt and .swt under jgl.wt, but that is not important
• The swt version is already defined as a variable in the main pom file under the property name : version.swt. That would be nice to remove the swt-version property you defined in emugl-gl-swt and reuse version.swt. Note we have 3.105.3 and you provide 3.116.100.
• I have the following exception that you might know when I run the application. Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. I added this to the pom but it only work when I ask for the poms of my os (mac). Would you recommend a setting that work for everybody? Any link explaining this welcome, I mainly fell on 9-years old discussions about it :)

<dependencies>
<!-- <dependency>
	<groupId>org.eclipse.platform</groupId>
	<artifactId>org.eclipse.swt.gtk.linux.x86_64</artifactId>
	<optional>true</optional>
	<version>${version.swt}</version>
</dependency>

<dependency>
	<groupId>org.eclipse.platform</groupId>
	<artifactId>org.eclipse.swt.win32.win32.x86_64</artifactId>
	<optional>true</optional>
	<version>${version.swt}</version>
</dependency>-->

<dependency>
	<groupId>org.eclipse.platform</groupId>
	<artifactId>org.eclipse.swt.cocoa.macosx.x86_64</artifactId>
	<optional>true</optional>
	<version>${version.swt}</version>
</dependency>
</dependencies>

Appart of it, your bezcurv example is working, congratulations! I noticed the first frame does not render and one need to resize the canvas to trigger repaint. I looked and see that your JGLCanvas paint listener is not invoked when the app prompts - at least on my mac. Is there any additional initialization event you may support?

Note that EmulGLCanvas.initGLUT best shows how jGL expect you to define the display and reshape function in jGL. I do not like it a lot but kept it as is for now.

myUT.glutCreateWindow(this); // refer to EmulGLCanvas
myUT.glutDisplayFunc("doRender"); // refer to EmulGLCanvas.doRender()
myUT.glutReshapeFunc("doReshape"); // ..

[laeubi]

The SWT needs to be used according to the platform you are running, one can try to play around a bit with maven profiles, but for the first testing steps I descended to keep it as simple as possible just to see if its working. The reason is that SWT itself has native bindings for each os, but uses a specific artifact for each of them to keep the size low.
The resize was not necessary on Linux, but I think we can find a solution here also, the idea here mainly is that the rendering is driven by SWT and not manually, but as you said we might better discuss this on a PR I'll try to rebase and open one, and as you have noticed I din't have yet tested all part of the build but I think that should be all solvable.

[laeubi]

I created #193 but it needs approval from a maintainer.