OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

OSG in Gtk3 GLArea

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Fri Jun 01, 2018 10:11 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi all,

First, a bit of background, then some questions:

My company has a machine controller application that I wrote that uses OSG for rendering machine status into a Gtk widget using the (old) gtkglext library. This worked up to about Gtk 3.10 (Ubuntu 14.04), but since we are being forced to upgrade to Gtk 3.18 (Ubuntu 16.04) our old hack doesn't work.

gtkglext is no longer supported, and in their wisdom the gtk developers are dragging us all kicking and screaming into the OpenGL 3.2 world, forcing us to use "core profile" (whatever that is). We now have to use GLArea widget, which is basically no problem, except that running OSG from the 'render' callback does nothing except draw the background color and then issue a bunch of

detected OpenGL error 'invalid operation' (blah blah)

messages.

So the questions are:

1 - is there any way to coax OSG to emit only this new-fangled core profile calls when we call Viewer::frame() from within the Gtk GLArea widget render callback?

2 - failing that, is it possible to fool GLArea by (for example) getting OSG to render into a buffer, using good old glBegin/End that's now a no-no, then somehow getting that buffer to the GLArea context using the sanctioned commands?

3 - has anyone out there got OSG rendering to Gtk GLArea, and willing to share code? (I can't believe nobody is doing this, but the google is surprisingly unhelpful).

Regards,
MT
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Jun 04, 2018 8:42 am    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi MT, (Mean Taipan, is that you're real name? You go by Mean? Sorry
but it's hard to assume that you are older than 6... if you are 6,
awesome, if you're not, ouch perhaps you should start communicating
with a form near to your actual age as your probably aren't conveying
the right tone/image.)

If GTK is dropping non GL core profile support, than wow, that's even
bigger an own goal as large as the one that Apple did to themselves.
One of the biggest value adds of GL is backwards/forwards
compatibility so to just discard this is a stupid decision.

How to get around it, on the OSG side the only thing you'll be able to
do with a GTK created core profile GL context is build it against
GLCORE from the ground up and just uses shaders in your application
like you now have to do under OSX.

The other alternative is to create your own graphics context on a Gtk
widget. I have no clue how to do this as I'm no Gtk user

Finally you could just ditch Gtk and use an Windowing API that doesn't
shoot itself in the foot.

Cheers,
Robert.



On 1 June 2018 at 23:11, Mean Taipan <> wrote:
Quote:
Hi all,

First, a bit of background, then some questions:

My company has a machine controller application that I wrote that uses OSG for rendering machine status into a Gtk widget using the (old) gtkglext library. This worked up to about Gtk 3.10 (Ubuntu 14.04), but since we are being forced to upgrade to Gtk 3.18 (Ubuntu 16.04) our old hack doesn't work.

gtkglext is no longer supported, and in their wisdom the gtk developers are dragging us all kicking and screaming into the OpenGL 3.2 world, forcing us to use "core profile" (whatever that is). We now have to use GLArea widget, which is basically no problem, except that running OSG from the 'render' callback does nothing except draw the background color and then issue a bunch of

detected OpenGL error 'invalid operation' (blah blah)

messages.

So the questions are:

1 - is there any way to coax OSG to emit only this new-fangled core profile calls when we call Viewer::frame() from within the Gtk GLArea widget render callback?

2 - failing that, is it possible to fool GLArea by (for example) getting OSG to render into a buffer, using good old glBegin/End that's now a no-no, then somehow getting that buffer to the GLArea context using the sanctioned commands?

3 - has anyone out there got OSG rendering to Gtk GLArea, and willing to share code? (I can't believe nobody is doing this, but the google is surprisingly unhelpful).

Regards,
MT

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73920#73920








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
kornerr
Appreciator


Joined: 01 Oct 2013
Posts: 265

PostPosted: Mon Jun 04, 2018 12:39 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi, Robert.

Quote:
that's even bigger an own goal as large as the one that Apple did to themselves.

Can you please clarify what Apple did?

On 4 June 2018 at 11:42, Robert Osfield <> wrote:
Quote:
Hi MT, (Mean Taipan, is that you're real name? You go by Mean? Sorry
but it's hard to assume that you are older than 6... if you are 6,
awesome, if you're not, ouch perhaps you should start communicating
with a form near to your actual age as your probably aren't conveying
the right tone/image.)

If GTK is dropping non GL core profile support, than wow, that's even
bigger an own goal as large as the one that Apple did to themselves.
One of the biggest value adds of GL is backwards/forwards
compatibility so to just discard this is a stupid decision.

How to get around it, on the OSG side the only thing you'll be able to
do with a GTK created core profile GL context is build it against
GLCORE from the ground up and just uses shaders in your application
like you now have to do under OSX.

The other alternative is to create your own graphics context on a Gtk
widget. I have no clue how to do this as I'm no Gtk user

Finally you could just ditch Gtk and use an Windowing API that doesn't
shoot itself in the foot.

Cheers,
Robert.



On 1 June 2018 at 23:11, Mean Taipan <> wrote:
Quote:
Hi all,

First, a bit of background, then some questions:

My company has a machine controller application that I wrote that uses OSG for rendering machine status into a Gtk widget using the (old) gtkglext library. This worked up to about Gtk 3.10 (Ubuntu 14.04), but since we are being forced to upgrade to Gtk 3.18 (Ubuntu 16.04) our old hack doesn't work.

gtkglext is no longer supported, and in their wisdom the gtk developers are dragging us all kicking and screaming into the OpenGL 3.2 world, forcing us to use "core profile" (whatever that is). We now have to use GLArea widget, which is basically no problem, except that running OSG from the 'render' callback does nothing except draw the background color and then issue a bunch of

detected OpenGL error 'invalid operation' (blah blah)

messages.

So the questions are:

1 - is there any way to coax OSG to emit only this new-fangled core profile calls when we call Viewer::frame() from within the Gtk GLArea widget render callback?

2 - failing that, is it possible to fool GLArea by (for example) getting OSG to render into a buffer, using good old glBegin/End that's now a no-no, then somehow getting that buffer to the GLArea context using the sanctioned commands?

3 - has anyone out there got OSG rendering to Gtk GLArea, and willing to share code? (I can't believe nobody is doing this, but the google is surprisingly unhelpful).

Regards,
MT

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73920#73920









------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Jun 04, 2018 12:48 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

On 4 June 2018 at 13:39, michael kapelko <> wrote:
Quote:
Hi, Robert.

Quote:
that's even bigger an own goal as large as the one that Apple did to themselves.

Can you please clarify what Apple did?

All modern GL features are only available if you use Core Profile, so
you can't mix and match fixed function pipeline usage with modern GL
usage.

Linux and Windows the GL drivers support both Core Profile and
backwards compatibility so it's far more flexible for application
developers, you aren't forced to ignore new features or forced to find
replacements for old features.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Mon Jun 04, 2018 2:31 pm    Post subject:
Reply with quote

Thanks for the reply. Don't know what I said to deserve the introductory put-down, but anyway if my only reasonable choice is to

Quote:
How to get around it, on the OSG side the only thing you'll be able to
do with a GTK created core profile GL context is build it against
GLCORE from the ground up and just uses shaders in your application
like you now have to do under OSX.


then please clarify a few things:

There are no direct openGL calls in my app; I rely on OSG to render the models and that's it (and of course I don't know what Gtk does under the covers). So I'm not sure how using just shaders in my program is relevant. Aren't there default ones? Do I need to enable some as a replacement for where I used to glBegin/End? If so, where is the best place to start reading about it?

I did build the latest stable OSG from source, but I would appreciate if you could point to the appropriate documentation for "building against GLCore from scratch". Hopefully it's just some magic -D compiler options.

At present, I am actually trying a work-around which is to render to a texture or pbuffer, with a context created by OSG, then basically copy that over to the normal 2D engine like Cairo. Inefficient, but it may work OK for us since the 3D display is not full-screen.


Regards,
John (since my randomly selected pseudonym makes it impossible for you to treat me as anything but an idiot, please, go ahead and call me 'John'.)
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Jun 04, 2018 4:40 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

HI ?

On 4 June 2018 at 15:31, Mean Taipan wrote:
Quote:
Thanks for the reply. Don't know what I said to deserve the introductory put-down, but anyway if my only reasonable choice is to

I like many others use the osg-users mailing list that is paired with
the forum, so we get your full Mean Taipan and email address. It's
your choice what you put in your handle but you should be aware that
it comes across as really immature. Ask yourself, how do you
introduce yourself in person when you plan to have a respectful
conversion with someone. Do you start off by being childish and
disrespectful?

This is an important issue because I have to handle support for many
hundreds of people (tens of thousands over the years), when people
start off with the a tone that id not mature it can lead to others not
being respectful or constructive. I've been an open source project
lead for 18 years, I know the types of things that lead to flame feats
and un constructive discussions. This is why I raise the flag on
childish/disrespectful handles and try to establish the right tone
early on - we are adults here who just want to write good code.

Quote:
then please clarify a few things:

There are no direct openGL calls in my app; I rely on OSG to render the models and that's it (and of course I don't know what Gtk does under the covers). So I'm not sure how using just shaders in my program is relevant. Aren't there default ones? Do I need to enable some as a replacement for where I used to glBegin/End? If so, where is the best place to start reading about it?

Independent from the GL core profile you absolutely should replace all
cases of glBeing/glEnd in your code, it's emulated at best by the
driver, it's very slow, and not supported at all under GLES and modern
GL. Modern OSG doesn't touch it either. glBein/glEnd is from the
90's, it's use has long been discouraged.

Quote:
I did build the latest stable OSG from source, but I would appreciate if you could point to the appropriate documentation for "building against GLCore from scratch". Hopefully it's just some magic -D compiler options.

Simply set the OPENGL_PROFILE when invoking the OSG.

cmake -DOPENGL_PROFILE=GLCORE .
make


Quote:
At present, I am actually trying a work-around which is to render to a texture or pbuffer, with a context created by OSG, then basically copy that over to the normal 2D engine like Cairo. Inefficient, but it may work OK for us since the 3D display is not full-screen.

Quote:
Regards,
John (since my randomly selected pseudonym makes it impossible for you to treat me as anything but an idiot, please, go ahead and call me 'John'.)

Or just use you own real first name, I much prefer honesty over
"games" and "fronts". Treat people like you would a family, friend or
colleague, just treat them with respect, starting off with some fa├žade
is really just a form of deceit. Do I want your whole life story? No.
A simple human first name, even better your own first name is perfect.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Mon Jun 04, 2018 5:34 pm    Post subject:
Reply with quote

OK, sorry I was not aware from the registration that it would be prominent let alone offensive. Even though I'm close to 60, rather than 6, and have been a software developer for 40 years, I can still learn a few new things, like that just because I expect and don't care that people use dumb pseudonyms on the Internet, other people are not severely affected. My bad, and you and my fellow forum users have my sincerest apology.

Unfortunately, the forum profile does not allow changing the name so I will create a new registration if I have a new question, hopefully one that won't be so irritating.
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Mon Jun 04, 2018 7:00 pm    Post subject:
Reply with quote

Again, my apologies but I can't delete this account. Moderators, please do it ASAP, no problem for me. (I won't try creating a new account until then, since I need to use the same email).

But in the meantime, if you'll bear with me, I recompiled osg with -DOPENGL_PROFILE=GLCORE but it triggers

Code:
Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..)


if there is any geometry. Vastly fewer errors than before, in fact only one, but still a black screen. So I'm probably missing something. The sequence of events is:

- when constructing the Viewer subclass, when the window is realized, it calls setUpViewerAsEmbeddedInWindow().
- when it is time to render, Gtk has already made the GL context 'current', so the draw callback just calls Viewer::frame().

So, if it's not too much trouble, someone please point out how I can get some finer debug granularity so I can chase down the error myself, or advise on what needs to precede the frame() call.

Regards,
SJH
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Jun 04, 2018 7:16 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi SJH,

On 4 June 2018 at 20:00, Mean Taipan <> wrote:
Quote:
Again, my apologies but I can't delete this account. Moderators, please do it ASAP, no problem for me. (I won't try creating a new account until then, since I need to use the same email).

I can't help with this myself as I'm the admin of the mailing list,
the forum is a community effort where the original creator has now
moved on. I am looking to move away, ideally we'll have one tool for
both mailing list and forun. On the short list is simply using the
openscengraph googlegroups, alas I'm waiting on the person who set
this up to transfer ownership and so far gone awol... I can only
really control what I have direct control over.

Quote:
But in the meantime, if you'll bear with me, I recompiled osg with -DOPENGL_PROFILE=GLCORE but it triggers


Code:
Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..)

Your scene graph probably is using fixed function state of some kind
that is triggering the error. Using GL Core Profile is not a small
step, it requires all your fixed function state to be replaced by
shaders. Many users have taken this step - it's essential for GLES2,
but most will stick with the GL2 profile and have backwards
compatibility. Sometimes applications can be moved across easily,
others it far more difficult. I don't know anything about your
application/graphics usage so can't say where you might fit on the
spectrum.

There has been lots of discussion about this topic so I won't go into
that here, just have a search through the archives.

Quote:
if there is any geometry. Vastly fewer errors than before, in fact only one, but still a black screen. So I'm probably missing something. The sequence of events is:

- when constructing the Viewer subclass, when the window is realized, it calls setUpViewerAsEmbeddedInWindow().
- when it is time to render, Gtk has already made the GL context 'current', so the draw callback just calls Viewer::frame().

So, if it's not too much trouble, someone please point out how I can get some finer debug granularity so I can chase down the error myself, or advise on what needs to precede the frame() call.

You can get the OSG to report GL errors more fine grained by setting
the OSG_GL_ERROR_CHECKING env var to ON. To list all the env vars run
:

osgviewer --help-env

Robert


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Jun 04, 2018 7:28 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

On 4 June 2018 at 18:34, Mean Taipan <> wrote:
Quote:
OK, sorry I was not aware from the registration that it would be prominent let alone offensive. Even though I'm close to 60, rather than 6, and have been a software developer for 40 years, I can still learn a few new things, like that just because I expect and don't care that people use dumb pseudonyms on the Internet, other people are not severely affected. My bad, and you and my fellow forum users have my sincerest apology.

No problem, thanks for taking steps to improve your name. The issue
with non human names is a nightmare for a project lead like myself.
You have dozens of different conversations each day, hundreds through
the month on various different venues - some on github, some on email
direct, some via the forum/osg-uses ML, if everyone uses the same
proper human name across all these platforms you can use normal human
tracking of who's who and what you've said to whom, when the numbers
of contacts goes up then it gets harder to keep track but it's more
doable.

Once people start introducing non human names, and use one name one
place, another somewhere else it becomes far far harder to know who's
said what and when, it rapidly becomes a nightmare. Something that
should be straight forward then requires any extra level of conscious
unpicking of the indirections that these psuedonames introduce. What
might seem a "convenience" for end users to pick any name they wish
for any whimsical reason becomes are serious burden, and as the years
go by the problem has gotten worse. It's just horrible to have to
wade through this stuff.

It's just so much more efficient to use proper human names right
across all mediums of communication, no indirections, leverage
existing brain pathways for remembering who's who. Humans came up
with these names to help communication, it's one of the clever bits of
societal glue then enables civilizations to be cohesive and grow. One
you loose face to face contact it becomes even more important not less
as you need all the cues you can get.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Tue Jun 05, 2018 6:47 am    Post subject:
Reply with quote

For now I have given up on trying to use core profile (my limited OpenGL knowledge is way obsolete), so I'm falling back to the previously mentioned workaround of rendering to a pbuffer and copying that back to the normal 2D engine.

Basing it around the osgscreencapture.cpp example, as if the --pbuffer-only option was used, it's working in the simplest case, but resizing the window does not work (only the original window size image is placed in the lower left of the resulting osg::Image, with the rest padded out with transparent pix).

I don't understand why, in the example, the following code is used (straightened out for the --pbuffer-only case):

Code:
    osg::ref_ptr<osg::GraphicsContext> pbuffer;
        osg::ref_ptr<osg::GraphicsContext::Traits> traits = new osg::GraphicsContext::Traits;
        ...
        traits->pbuffer = true;
        ...
        pbuffer = osg::GraphicsContext::createGraphicsContext(traits.get());
         
        ...

        osg::ref_ptr<osg::Camera> camera = new osg::Camera;
        camera->setGraphicsContext(pbuffer.get());
        camera->setViewport(new osg::Viewport(0,0,width,height));
        GLenum buffer = pbuffer->getTraits()->doubleBuffer ? GL_BACK : GL_FRONT;
        camera->setDrawBuffer(buffer);
        camera->setReadBuffer(buffer);
        camera->setFinalDrawCallback(new WindowCaptureCallback(mode, position, readBuffer));

        viewer.addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());

        viewer.realize();

    return viewer.run();


So why is addSlave() then realize() necessary?

I tried simplifying it to just setting the pbuffer GraphicsContext directly on viewer.getCamera() (before realize()) but that results in a completely empty image. But the normal viewer.getCamera() seems like a waste if I'm not using it.

It also fails if viewer.realize() is removed.

Anyway, the bigger problem is resizing. In my viewer subclass, when the window is resized it calls resized() on the relevant GCs, which makes a bigger image but padded with transparent (I can't see on-screen in real time as yet, but instead it is writing the Image to a .png file).

FWIW, here is my code to set up the pbuffer GC and the resize method:

Code:
void MyViewer::embedInMemory(int x, int y, int width, int height)
{
    osg::ref_ptr<osg::Camera> camera = new osg::Camera;
    GLenum readBuffer = GL_BACK;
    WindowCaptureCallback::FramePosition position = WindowCaptureCallback::END_FRAME;
    WindowCaptureCallback::Mode mode = WindowCaptureCallback::READ_PIXELS;
    setThreadingModel(SingleThreaded);
    _gw = new GraphicsWindowMemory(x,y,width,height);
    camera->setViewport(new osg::Viewport(0,0,width,height));
    camera->setGraphicsContext(_gw);
    GLenum buffer = _gw->getTraits()->doubleBuffer ? GL_BACK : GL_FRONT;
    camera->setDrawBuffer(buffer);
    camera->setReadBuffer(buffer);
    camera->setFinalDrawCallback(new WindowCaptureCallback(mode, position, readBuffer));
   
    addSlave(camera.get(), osg::Matrixd(), osg::Matrixd());
    realize();
}

void MyViewer::reconfigure(int x, int y, int width, int height)
{
    _queue.windowResize(x, y, width, height);  // osgGA::EventQueue & _queue
    if (_gw->isRealized()) {  // _gw is my GC created above
        _gw->makeCurrent();
    }
    _gw->resized(x, y, width, height);
    if (getCamera()->getGraphicsContext() && getCamera()->getGraphicsContext()->isRealized()) {
        getCamera()->getGraphicsContext()->resized(x, y, width, height);
        getCamera()->setViewport(new osg::Viewport(0,0,width,height));
        getCamera()->setProjectionMatrixAsPerspective(30.0f, static_cast<double>(width)/static_cast<double>(height), 1.0f, 10000.0f);
    }
}



Maybe you can point out the dumb mistake I have made.

[Sorry if the code has funny chars instead of spaces; it seems to be spaces in the text widget but preview looks a bit weird.]

Regards,
SJH
Back to top
View user's profile Send private message
SMesserschmidt (Sebastian Messerschmidt)
Forum Moderator


Joined: 10 Sep 2013
Posts: 814

PostPosted: Tue Jun 05, 2018 7:11 am    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi,


Am 04.06.2018 um 21:00 schrieb Mean Taipan:
Quote:
Again, my apologies but I can't delete this account. Moderators, please do it ASAP, no problem for me. (I won't try creating a new account until then, since I need to use the same email).


Simply tell me the name you need your profile changed to or write me a
forum-message and I will do so.

Cheers
Sebastian

Quote:

But in the meantime, if you'll bear with me, I recompiled osg with -DOPENGL_PROFILE=GLCORE but it triggers


Code:
Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..)



if there is any geometry. Vastly fewer errors than before, in fact only one, but still a black screen. So I'm probably missing something. The sequence of events is:

- when constructing the Viewer subclass, when the window is realized, it calls setUpViewerAsEmbeddedInWindow().
- when it is time to render, Gtk has already made the GL context 'current', so the draw callback just calls Viewer::frame().

So, if it's not too much trouble, someone please point out how I can get some finer debug granularity so I can chase down the error myself, or advise on what needs to precede the frame() call.

Regards,
SJH

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73963#73963









------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Tue Jun 05, 2018 7:53 am    Post subject:
OSG in Gtk3 GLArea
Reply with quote

Hi SJH, (I'm afriad this still isn't great, how is my brain supposed
to parse SJH? S J H? Attempt to blurt it out as single word? Is this
how people address you face to face? Please just a human name is
best. :)

I haven't personally tried the approach of mixing and matching
different types of windows before. I think perhaps for you it is the
line of least resistance though, but as I haven't ever tried to
implement I don't know off the top of my head all the pitfalls.

PixelBuffers are fixed size so once you create them they can't be
resized like a conventional GraphicsWindow. If the window you are
copying the data to is resized then you'll either need to allocate a
new PixelBuffer or allocate an oversized PixelBuffer at start up and
then use a varying size of viewport to adjust it's size to the size of
the window.

The other cheeky way to do it would be to disable resize on the
window. Perhaps as a first step this is what I'd do, get everything
else working well then go back an work on handling resize.

FYI, I may end up attempting to do something like you are doing during
my Vulkan experiments, just to see if I can assign Vulkan rendered
graphics to a buffer then mix it with an OSG or other window. If this
ends up being feasible and useful some of the supporting functionality
might be rolled into the next OSG release, and just might help out in
your case a bit too. This is all massively speculatively so please
don't expect anything, just be aware it's one of the many different
possibilities that I have in mind.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mean_taipan
Newbie


Joined: 01 Jun 2018
Posts: 10

PostPosted: Tue Jun 05, 2018 2:25 pm    Post subject:
Reply with quote

Hi Sebastian: please put me down as 'Steve Hardy'.
Robert: I've used that sig for at least 30 years so it is semi-automatic, but when I have the new name (thanks Sebastian) I can use the auto-generated one and we should all be happy.

Since resizing the window is not done often, the overhead of re-allocating the pixel buffer is not an issue, so I'll try that.

Although I can certainly make a fixed window size, I would hear no end of complaints from the boss :-)

Regards,
Steve
Back to top
View user's profile Send private message
kornerr
Appreciator


Joined: 01 Oct 2013
Posts: 265

PostPosted: Tue Jun 05, 2018 2:32 pm    Post subject:
OSG in Gtk3 GLArea
Reply with quote

John (aka MT), make sure you use VBO
(osg::Geometry::setUseVertexBufferObjects) on your geometry if you're
rendering with GLES.

On 5 June 2018 at 10:53, Robert Osfield <> wrote:
Quote:
Hi SJH, (I'm afriad this still isn't great, how is my brain supposed
to parse SJH? S J H? Attempt to blurt it out as single word? Is this
how people address you face to face? Please just a human name is
best. :)

I haven't personally tried the approach of mixing and matching
different types of windows before. I think perhaps for you it is the
line of least resistance though, but as I haven't ever tried to
implement I don't know off the top of my head all the pitfalls.

PixelBuffers are fixed size so once you create them they can't be
resized like a conventional GraphicsWindow. If the window you are
copying the data to is resized then you'll either need to allocate a
new PixelBuffer or allocate an oversized PixelBuffer at start up and
then use a varying size of viewport to adjust it's size to the size of
the window.

The other cheeky way to do it would be to disable resize on the
window. Perhaps as a first step this is what I'd do, get everything
else working well then go back an work on handling resize.

FYI, I may end up attempting to do something like you are doing during
my Vulkan experiments, just to see if I can assign Vulkan rendered
graphics to a buffer then mix it with an OSG or other window. If this
ends up being feasible and useful some of the supporting functionality
might be rolled into the next OSG release, and just might help out in
your case a bit too. This is all massively speculatively so please
don't expect anything, just be aware it's one of the many different
possibilities that I have in mind.

Cheers,
Robert.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum



Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP