Menu
▾
▴
1 Attachments
#925 Patch to add multisample options in wxsGLCanvas
This patch adds 2 options in wxSmith, and more precisely in wxsglcanvas. These options modify the wxSmith build process for generating code and add the possibility to activate multisample (GL_MULTISAMPLE), option used to activate polygon antialiasing. These options are conditionnaly added at compile time if wxWidgets version is >= 3.0.0.
Patch modified to avoid unwanted changes in comments
Is this still applicable?
Yes it is. It is included in my own builds.
Those parameters only have two values (0 or 1, 0 or 4)? What happens if someone sets other values?
I am asking because two bools may be a clearer or safer option. I know nothing about GLcanvas.
.
Sorry for the late answer. Posts where in my spam...
As far I have tested, giving other values does not make problems.
WX_GL_SAMPLE_BUFFERS seems to be interpreted as a boolean; so 0 is false, anything else is true;
WX_GL_SAMPLES is an antialiasing parameter. 0 or 1 means no antialiasing, 4 is for 2x2 antialiasing. I have tested different values, 2, 3, 5 ... it does not crash (at least important!), and apparently gives a result as if it was rounded to a correct value (2 or 3 <=> 1, 5, 6... <=> 4). If I remember well, I have tested 9 (for 3x3).
OK. My remaining concern is about properties' names, they look more a hint to the value than a proper name. Do you like this change?
1 for multisampling support (antialiasing) -> Multisampling support
4 for 2x2 antialiasing supersampling -> Antialiasing supersampling
Why not.
The problem I see is that the use has to set a numerical value (0, 1, 4 or more in the second case) and your proposition does not give indications). May be something like :
Multisampling support (1)
Antialiasing supersampling (4 for 2x2)
is better. But as the text string is quite long, the indications may be masked by the width of the resource tab.
Fixed in [r12554]. I have used the tooltip support for long properties added by [r12553] to show usage information, I hope it is OK for you.
Related
Commit: [r12553]
Commit: [r12554]
Not related to the ticket but, does the generated code compile on your system?. The constructors do not match, and the new constructor appeared in wx3.1.0, not in wx3.0.0
Yes, for me the generated code works on my application. So, do you suggest to replace a check wxCHECK_VERSION(3,0,0) by wxCHECK_VERSION(3,1,0), I suppose the one before
GLCanvas = new wxGLCanvas(...) ? Why not. On my PC it does not change anything.
Nevertheless, I thought that the change was between 2.8 and 3.0 (don't remember what it was for 2.9)
Last edit: Gerard DURAND 2021-12-05
wxWidgets 3.1.0 introduced a new constructor for wxGLCanvas, see [r12556] for more information.. I expect this change does not break existing code, tell me if you see something weird.
Related
Commit: [r12556]
Unfortunately this patch breaks my code compilation:
I have conflicts between the old const int* AttribList and the new const wxGLAttributes& AttribList.
I tried to add some #if wxCHECK_VERSION(3,1,0) in my code but until now I have not found the good way to use it.
I need some more tries...
Do you use the attribute list after construction?. Once the object is created, which contructor was used should be irrelevant...
What conflicts do you get?. The new constructor may assert if an attribute is not valid, for example a request for an invalid pixel format. Using the values set by wcGLAttributes::Default() the asserts should go away.
OK, found...
My code is supposed to compile and work on different machines, with wxWidgets 2.8.12, 3.0.x or 3.1.x. Normally, it could be a PC Windows or a Linux machine.
I have finally just modified the order of some parameters in constructors because my old const int* AttribList had a default value but I have not been able to put a default value for the wxGLAttributes& AttribList so, in that case, all the parameters without default values were not at the beginning of the argument list. Now it should be correct (but only tested on a PC with wxWidgets 3.1.5).