FAQ
Hey all,

The new Go QML OpenGL API is available for experimentation. The blog
post details what has changed, why, how it was done, and also brings
up a few points where contributions would be appreciated at this
stage:

http://blog.labix.org/2014/08/29/the-new-go-qml-opengl-api


gustavo @ http://niemeyer.net

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ignazio Di Napoli at Sep 1, 2014 at 1:35 pm
    Hi Gustavo,

    thank you for your hard work.

    In docs you write: // The returned API must not be used after the provided
    OpenGL context becomes invalid.
    How do I know it's time to get another API?


    Thank you
    Ignazio


    On Friday, August 29, 2014 4:35:10 PM UTC+2, Gustavo Niemeyer wrote:

    Hey all,

    The new Go QML OpenGL API is available for experimentation. The blog
    post details what has changed, why, how it was done, and also brings
    up a few points where contributions would be appreciated at this
    stage:

    http://blog.labix.org/2014/08/29/the-new-go-qml-opengl-api


    gustavo @ http://niemeyer.net
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 1, 2014 at 3:13 pm
    Hey Ignazio,
    On Mon, Sep 1, 2014 at 10:35 AM, Ignazio Di Napoli wrote:
    In docs you write: // The returned API must not be used after the provided
    OpenGL context becomes invalid.
    How do I know it's time to get another API?
    For now I recommend just picking a new API when entering the Paint method.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ignazio Di Napoli at Sep 1, 2014 at 1:48 pm
    Other question:

    Is there a reason why Uniform has a type while Attrib has not?



    On Friday, August 29, 2014 4:35:10 PM UTC+2, Gustavo Niemeyer wrote:

    Hey all,

    The new Go QML OpenGL API is available for experimentation. The blog
    post details what has changed, why, how it was done, and also brings
    up a few points where contributions would be appreciated at this
    stage:

    http://blog.labix.org/2014/08/29/the-new-go-qml-opengl-api


    gustavo @ http://niemeyer.net
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 1, 2014 at 3:16 pm

    On Mon, Sep 1, 2014 at 10:48 AM, Ignazio Di Napoli wrote:
    Is there a reason why Uniform has a type while Attrib has not?
    Implementing these types and ensuring they're being used in the right
    spots is still in progress, as described in the post.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ignazio Di Napoli at Sep 1, 2014 at 3:59 pm
    Even more questions / bug reports, following the conversion of my go-gl
    program to go-qml.

    - don't you think glbase.Boolean should map to bool?
    - GetAttribLocation and GetUniformLocation should take strings as input,
    not []byte
    - for example, in glUniformMatrix4fv len(value) should be 16*count, not 4
    as checked in code [1]
    - gl.ClearColor for es2 requires glbase.Clampf, which glbase does not
    declare

    And for now, it only compiles, not drawing at all (but I have to
    double-check my work).


    Thank you
    Ignazio


    [1]:
              <command>
                 <proto>void <name>glUniformMatrix4fv</name></proto>
                 <param><ptype>GLint</ptype> <name>location</name></param>
                 <param><ptype>GLsizei</ptype> <name>count</name></param>
                 <param group="Boolean"><ptype>GLboolean</ptype>
    <name>transpose</name></param>
                 <param len="count*16">const <ptype>GLfloat</ptype>
    *<name>value</name></param>
             </command>

    On Monday, September 1, 2014 5:16:48 PM UTC+2, Gustavo Niemeyer wrote:

    On Mon, Sep 1, 2014 at 10:48 AM, Ignazio Di Napoli <necl...@gmail.com
    <javascript:>> wrote:
    Is there a reason why Uniform has a type while Attrib has not?
    Implementing these types and ensuring they're being used in the right
    spots is still in progress, as described in the post.


    gustavo @ http://niemeyer.net
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 1, 2014 at 4:59 pm

    On Mon, Sep 1, 2014 at 12:59 PM, Ignazio Di Napoli wrote:
    Even more questions / bug reports, following the conversion of my go-gl
    program to go-qml.
    Thanks for those. Please keep them coming.
    - don't you think glbase.Boolean should map to bool?
    Yes, I'll do that today. It requires a couple of tweaks in the main
    conversion logic.
    - GetAttribLocation and GetUniformLocation should take strings as input, not
    []byte
    Indeed. Let's fix that. We'll certainly have more cases where the
    default translation logic is not the right thing to do.
    - for example, in glUniformMatrix4fv len(value) should be 16*count, not 4 as
    checked in code [1]
    Indeed. The logic for the constraint on the number of elements is
    generic, based on the function suffix (4fv), and it is not correct for
    these functions.
    - gl.ClearColor for es2 requires glbase.Clampf, which glbase does not
    declare
    Indeed. Added both Clampf and Clampd. Please just update it.
    And for now, it only compiles, not drawing at all (but I have to
    double-check my work).
    Let us know how it goes.



    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 2, 2014 at 4:35 am
    These issues were all resolved, except for Uniform*v which were
    temporarily disabled until the lengths are properly sorted (other
    Uniform* functions may be used meanwhile).

    There are also richer function tweaks that turn these issues into
    trivial problems to solve, and proper documentation for them, if you
    want to help:

    https://github.com/go-qml/qml/blob/v1/gl/gengl/funcs.go#L3

    On Mon, Sep 1, 2014 at 1:59 PM, Gustavo Niemeyer wrote:
    On Mon, Sep 1, 2014 at 12:59 PM, Ignazio Di Napoli wrote:
    Even more questions / bug reports, following the conversion of my go-gl
    program to go-qml.
    Thanks for those. Please keep them coming.
    - don't you think glbase.Boolean should map to bool?
    Yes, I'll do that today. It requires a couple of tweaks in the main
    conversion logic.
    - GetAttribLocation and GetUniformLocation should take strings as input, not
    []byte
    Indeed. Let's fix that. We'll certainly have more cases where the
    default translation logic is not the right thing to do.
    - for example, in glUniformMatrix4fv len(value) should be 16*count, not 4 as
    checked in code [1]
    Indeed. The logic for the constraint on the number of elements is
    generic, based on the function suffix (4fv), and it is not correct for
    these functions.
    - gl.ClearColor for es2 requires glbase.Clampf, which glbase does not
    declare
    Indeed. Added both Clampf and Clampd. Please just update it.
    And for now, it only compiles, not drawing at all (but I have to
    double-check my work).
    Let us know how it goes.



    gustavo @ http://niemeyer.net


    --

    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ignazio Di Napoli at Sep 3, 2014 at 11:56 am

    On Tuesday, September 2, 2014 6:35:26 AM UTC+2, Gustavo Niemeyer wrote:
    These issues were all resolved, except for Uniform*v which were
    temporarily disabled until the lengths are properly sorted (other
    Uniform* functions may be used meanwhile).

    What about just disabling the check? That's what I understood, I've
    updated and now I'm stuck.
    I understand it could be a security issue, but it's temporary.

    Thank you

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ignazio Di Napoli at Sep 3, 2014 at 4:26 pm

    On Monday, September 1, 2014 6:59:28 PM UTC+2, Gustavo Niemeyer wrote:
    Even more questions / bug reports, following the conversion of my go-gl
    program to go-qml.
    Thanks for those. Please keep them coming.
    Ok! What is the best place to do that? This thread? An issue in github?
    Email?
    For today just one: GetProgramInfoLog should behave like GetShaderInfoLog
    (good tweak!), and both should return strings.

    And a question: are you sure docs should be part of funcTweakList?
    I suppose you are just specifying docs where it is needed, and plan to add
    default docs parsing the xhtml you link for the others.
    But docs take almost all the space, making it difficult to read the list.
    As he tweaks grow, it only gets worse.
    On the other hand keeping them together "forces" writing docs for each
    tweak.

    But maybe the best solution is to keep them together but split the list.
    You could make a package for tweaks, with a separate file for each tweak.
    Each file is named after the function and defines a variable (also named
    after the function).
    Then you use reflection to get all the variables in the package and build
    funcTweakList.

    Example: https://gist.github.com/anonymous/e5d8f1d43cfefb3c7ad6


    Thank you
    Ignazio

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 3, 2014 at 5:57 pm

    On Wed, Sep 3, 2014 at 1:26 PM, Ignazio Di Napoli wrote:
    Thanks for those. Please keep them coming.
    Ok! What is the best place to do that? This thread? An issue in github?
    Email?
    For today just one: GetProgramInfoLog should behave like GetShaderInfoLog
    (good tweak!), and both should return strings.
    Issues would be best. Most people are likely not interested in the
    details, and it allows tracking what's done and what's pending
    properly.

    I'm handling Uniform* now, and I'll take care of GetProgrammingInfoLog
    next, thanks again.
    And a question: are you sure docs should be part of funcTweakList?
    (...)

    Yes, I started with them separate, but it became clear that they
    should be together. The key point isn't just forcing the documentation
    to be written, but taking the documentation into account when
    polishing the function. The tweak logic and what the documentation
    describes are very tightly coupled.
    But docs take almost all the space, making it difficult to read the list. As
    he tweaks grow, it only gets worse.
    The list is large either way. Searching is the way to go.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Gutekanst at Sep 4, 2014 at 7:04 pm
    The goal is having a great OpenGL interface that just works with the
    qml package, no matter the platform. That's not currently available
    anywhere.

    Yeah, I did gather that much from your blog post. I am sorry though - I did
    a poor job communicating my questions clearly:

    1. Which OpenGL bindings have you looked at and what were the problems
    using QML with them?

    2. Have you already seen/looked at Glow <https://github.com/go-gl/glow> and
    what problems did you experience using it with QML? Was it literally
    incompatible with QML for some reason -- or was it mostly API preferences?
    Creating the API value is cheap. Don't worry about it.
    I have an existing project which uses non-QML OpenGL bindings (Glow GL 2.0)
    and I think I should be able to use it with QML without creating an
    entirely new version using QML-specific OpenGL bindings (that sounds like a
    lot of maintenance work!).

    4. Can you provide any insight as to why QML does invalidate the OpenGL
    context?

    5. If the context is truly invalid upon each Paint -- aren't all resources
    associated with it also invalidated (textures, etc)? Those can surely be
    pretty expensive to upload every paint?

    I really appreciate your time and all the work you've done on this,
    Stephen

    On Wed, Sep 3, 2014 at 10:56 AM, Gustavo Niemeyer wrote:
    On Wed, Sep 3, 2014 at 1:26 PM, Ignazio Di Napoli wrote:
    Thanks for those. Please keep them coming.
    Ok! What is the best place to do that? This thread? An issue in github?
    Email?
    For today just one: GetProgramInfoLog should behave like GetShaderInfoLog
    (good tweak!), and both should return strings.
    Issues would be best. Most people are likely not interested in the
    details, and it allows tracking what's done and what's pending
    properly.

    I'm handling Uniform* now, and I'll take care of GetProgrammingInfoLog
    next, thanks again.
    And a question: are you sure docs should be part of funcTweakList?
    (...)

    Yes, I started with them separate, but it became clear that they
    should be together. The key point isn't just forcing the documentation
    to be written, but taking the documentation into account when
    polishing the function. The tweak logic and what the documentation
    describes are very tightly coupled.
    But docs take almost all the space, making it difficult to read the list. As
    he tweaks grow, it only gets worse.
    The list is large either way. Searching is the way to go.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/1u5HnvwScDI/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Follow me on twitter @slimsag <https://twitter.com/slimsag>.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 4, 2014 at 7:32 pm

    On Thu, Sep 4, 2014 at 4:04 PM, Stephen Gutekanst wrote:
    The goal is having a great OpenGL interface that just works with the
    qml package, no matter the platform. That's not currently available
    anywhere.

    Yeah, I did gather that much from your blog post. I am sorry though - I did
    a poor job communicating my questions clearly:

    1. Which OpenGL bindings have you looked at and what were the problems using

    2. Have you already seen/looked at Glow and what problems did you experience
    using it with QML? Was it literally incompatible with QML for some reason --
    or was it mostly API preferences?
    QML with them?
    I've tried go-gl, for example [1], and there were symbol resolution
    problems due to how GL defines the API but not the symbol names, or
    the library names, or which versions are supported by which systems,
    in which local paths, and so on. These are common problems when
    dealing with GL, and they're already solved by Qt itself, which the
    qml package relies upon for its basics.

    [1] http://goo.gl/4wWKgX
    Creating the API value is cheap. Don't worry about it.
    I have an existing project which uses non-QML OpenGL bindings (Glow GL 2.0)
    and I think I should be able to use it with QML without creating an entirely
    new version using QML-specific OpenGL bindings (that sounds like a lot of
    maintenance work!).
    Porting from/to the OpenGL interface of the qml package to/from any
    other sanely designed OpenGL package should be trivial, since they're
    just a thin layer on top of the system libraries. That said, if you
    have an application entirely designed to work with OpenGL alone, then
    I'd recommend not using the qml package. It's just an unnecessary
    overhead if you're not using the convenience of the qml framework to
    build the application.
    4. Can you provide any insight as to why QML does invalidate the OpenGL
    context?
    It's not just about invalidating the context, but also about being
    able to have GL logic working properly on multiple threads, with
    multiple GL contexts active. When a specific API version is requested,
    the entry points are cached and associated with a GL context, so that
    API(p) call is simply a good hook point for us to be able to do that
    kind of analysis, and can be easily optimized away to become a NOOP in
    most cases.
    5. If the context is truly invalid upon each Paint -- aren't all resources
    associated with it also invalidated (textures, etc)? Those can surely be
    pretty expensive to upload every paint?
    The GL context is not invalidated on each Paint. That'd be very unreasonable.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Gutekanst at Sep 4, 2014 at 8:22 pm
    I see. Thanks for the detailed explanation, it's exactly what I was looking
    for!

    FWIW -- go-gl/gl (https://github.com/go-gl/gl) uses GLEW but Glow (
    https://github.com/go-gl/glow) does not.

    Stephen

    On Thu, Sep 4, 2014 at 12:31 PM, Gustavo Niemeyer wrote:

    On Thu, Sep 4, 2014 at 4:04 PM, Stephen Gutekanst
    wrote:
    The goal is having a great OpenGL interface that just works with the
    qml package, no matter the platform. That's not currently available
    anywhere.

    Yeah, I did gather that much from your blog post. I am sorry though - I did
    a poor job communicating my questions clearly:

    1. Which OpenGL bindings have you looked at and what were the problems using
    2. Have you already seen/looked at Glow and what problems did you
    experience
    using it with QML? Was it literally incompatible with QML for some reason --
    or was it mostly API preferences?
    QML with them?
    I've tried go-gl, for example [1], and there were symbol resolution
    problems due to how GL defines the API but not the symbol names, or
    the library names, or which versions are supported by which systems,
    in which local paths, and so on. These are common problems when
    dealing with GL, and they're already solved by Qt itself, which the
    qml package relies upon for its basics.

    [1] http://goo.gl/4wWKgX
    Creating the API value is cheap. Don't worry about it.
    I have an existing project which uses non-QML OpenGL bindings (Glow GL 2.0)
    and I think I should be able to use it with QML without creating an entirely
    new version using QML-specific OpenGL bindings (that sounds like a lot of
    maintenance work!).
    Porting from/to the OpenGL interface of the qml package to/from any
    other sanely designed OpenGL package should be trivial, since they're
    just a thin layer on top of the system libraries. That said, if you
    have an application entirely designed to work with OpenGL alone, then
    I'd recommend not using the qml package. It's just an unnecessary
    overhead if you're not using the convenience of the qml framework to
    build the application.
    4. Can you provide any insight as to why QML does invalidate the OpenGL
    context?
    It's not just about invalidating the context, but also about being
    able to have GL logic working properly on multiple threads, with
    multiple GL contexts active. When a specific API version is requested,
    the entry points are cached and associated with a GL context, so that
    API(p) call is simply a good hook point for us to be able to do that
    kind of analysis, and can be easily optimized away to become a NOOP in
    most cases.
    5. If the context is truly invalid upon each Paint -- aren't all resources
    associated with it also invalidated (textures, etc)? Those can surely be
    pretty expensive to upload every paint?
    The GL context is not invalidated on each Paint. That'd be very
    unreasonable.


    gustavo @ http://niemeyer.net


    --
    Follow me on twitter @slimsag <https://twitter.com/slimsag>.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 4, 2014 at 8:44 pm

    On Thu, Sep 4, 2014 at 5:22 PM, Stephen Gutekanst wrote:
    I see. Thanks for the detailed explanation, it's exactly what I was looking
    for!
    Glad it was helpful. Please drop a note if you need something. The
    mailing list has several helpful members as well.
    FWIW -- go-gl/gl (https://github.com/go-gl/gl) uses GLEW but Glow
    (https://github.com/go-gl/glow) does not.
    The problem remains the same.. it reimplements the resolution logic
    and other details (see notes on threading, for example) which have
    already been dealt with in the qml package. If the qml package is
    working, the OpenGL bindings ought to just work as well.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Gutekanst at Sep 2, 2014 at 8:53 pm
    Gustavo,

    Curious if you could describe what sort of reasoning you have for using
    your own OpenGL bindings, versus other ones available?

    Also, will there be a better way in the future to detect context
    invalidation rather than recreating the API upon each paint?

    Thanks for your time,
    Stephen
    On Friday, August 29, 2014 7:35:31 AM UTC-7, Gustavo Niemeyer wrote:

    Hey all,

    The new Go QML OpenGL API is available for experimentation. The blog
    post details what has changed, why, how it was done, and also brings
    up a few points where contributions would be appreciated at this
    stage:

    http://blog.labix.org/2014/08/29/the-new-go-qml-opengl-api


    gustavo @ http://niemeyer.net
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 2, 2014 at 10:09 pm
    Hi Stephen,

    On Tue, Sep 2, 2014 at 5:53 PM, Stephen Gutekanst
    wrote:
    Curious if you could describe what sort of reasoning you have for using your
    own OpenGL bindings, versus other ones available?
    The goal is having a great OpenGL interface that just works with the
    qml package, no matter the platform. That's not currently available
    anywhere.

    I suggest reading the blog post for some details:

    http://blog.labix.org/2014/08/29/the-new-go-qml-opengl-api
    Also, will there be a better way in the future to detect context
    invalidation rather than recreating the API upon each paint?
    Creating the API value is cheap. Don't worry about it.


    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 29, '14 at 2:35p
activeSep 4, '14 at 8:44p
posts17
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase