2020-10-26 11:39 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000028OTB-libGeneralpublic2008-12-15 11:02
Assigned Tochristop 
Summary0000028: OTB_GL_USE_ACCEL and external OTB programs
DescriptionThe solution introduced at:
is not fully satisfactory.

when compiling an external OTb program, internal OTB variables are not defined, thus resulting in the wrong configuration.

It would be better to find a more global solution (which works for all machines).

Possibilities includes:
- replacing the GL_QUADS by something simplier (and keeping the texture)
- replacing the glPixelZoom by some modification on glOrtho (and keeping the glDrawPixels)
TagsNo tags attached.
Attached Files

related to 0000055closedmickael Altenate viewer don't use OTB_GL_USE_ACCEL 



julien (administrator)

To find a proper solution to this bug, we would need to know the following things:
- What was the aim of the solution http://hg.orfeo-toolbox.org/OTB/rev/7fd18e37aa99 ?
- Does this solution fix the problem ?
- What is wrong with glPixelZoom ?


christop (administrator)

glPixelZoom (it's supposedly coming from that) is causing a problem with ati driver: dark stripes appear and change size when resizing the window.

The problem seems to be linked with the fact that the y zoom factor is negative (no problem if it is positive -> but the image is flipped). Couldn't find more information about this on the internet, but the problem appears also on pc-christophe when the ati driver is loaded.

Besides, glDrawPixels seems to be a slow solution and apparently using textures is recommended.


julien (administrator)

Ok. I understand that texture rendering is faster than raw pixels drawing. Was it noticeable when using the old viewer version ?

If the problem comes from the negative zoom factor, we could invert the pixel buffer using a reverse iterator and use a positive zoom factor instead. Would it fix the problem ?

Another problem is that on some windows platform, the display remains black. I would like to fix this along with the zoom factor problem.

Regarding the accelerated solution, it is probably the best when supporting graphical acceleration. I am not sure wheter it exists a simpler structure than GL_QUADS. But it would be too bad to let this piece of code aside. Maybe we could just add a boolean class member m_Use3DAcceleration set to false by default and document this ? Of course we would need to report this parameter in all applications.


christop (administrator)

The speed was not really an issue with the original version so the main reason for the new version is the bug with the ati.

If we revert the buffer before and use a positive zoom factor, it is also very likely to fix the problem (I only identified that yesterday).

Concerning windows plateforms, can you confirm that it is still black with:
- the new version (from yesterday)
- and an overlay image

Agree to put the default on the original version which seem safer now. Provided the parameter is reported for all applications.


julien (administrator)

Last edited: 2008-12-03 15:10

I can confirm that my display remains black even with the latest version, using overlays or not.

I will try to invert the buffer, though it will not be that simple (using a reverse iterator will invert both X and Y axis).


julien (administrator)

This is interesting: my display is no longer black if I use a positive zoom factor (but the image is inverted). So the two problems seem to be similar. I will write the inverted buffer routine and test it. Might be the end of one year of "my display is black, it must be the graphical board not beeing properly set".


julien (administrator)

It is working. Using an partially inverted buffer and positive zoom factors, the images are shown correctly, and there are no more black displays.

All we need to do now is to choose what to do with accelerated code :
- keep the CMake option,
- Use a boolean class member,
- Discard (not really a good solution).


julien (administrator)

The OTB_GL_USE_ACCEL has been reported in otbConfigure.h, which is included in otbImageWidgetBase.txx. This way, the external applications will automatically use the same set up than the lib.

We should also update the otb::ImageAlternateViewer gl and buffers routines. Will be done tomorrow.


christop (administrator)

Confirms that the original solution now works for me.
Can be kept as the default option.


christop (administrator)

The buffer should not be flipped when using the accelerated solution.


julien (administrator)

Right. How can we handle both cases ? I can add a #ifndef instruction, but it complexifies the code ...

What will happen if we draw the GL_QUADS corner in another order ? Will it flip the texture ?


julien (administrator)

It seems slower with the new code (not accelerated). Emmanuel, can you confirm this ?


christop (administrator)

>What will happen if we draw the GL_QUADS corner in another order ? Will it flip the texture ?

We can. But one of the interest of the GL_QUADS is to do the flipping directly in the video card (faster). The optimal way is to use the #ifdef but NOT inside the RebuildOpenGlBuffer() method: two methods should be created:
And only the call to the method should be in #ifdef

>It seems slower with the new code (not accelerated). Emmanuel, can you confirm this ?

Are you asking about the OTB_GL_USE_ACCEL=OFF between yesterday and today?


julien (administrator)

Agree. But only the index computation will change between both RebuildOpenGlBuffer() versions (and also for the overlay version), and that makes a lot of code duplication ...

I thougth that using OTB_GL_USE_ACCEL=OFF between yesterday and today seems slower. But it could be related to my platform.


julien (administrator)

One other side effect of this bug fix is that on some application using a FixedSizeFullResolutionImageWidget, there is now a black offset in the display. I thougth I fixed it (http://hg.orfeo-toolbox.org/OTB/rev/457a99e7bbff) but it seems more complex than that. This change has to be reverted in mercurial, and more investigation is required.


julien (administrator)

I fixed the offset problem.

I also added the inline methods GetBufferIndex() and GetRevertedBufferIndex(). In the RebuildOpenGlBuffer() and RebuildOpenGlImageOverlayBuffer(), either the first or the second is used to compute the index, depending on OTB_USE_GL_ACCEL.

This should fix the problem mentionned by Emmanuel. Can you confirm that it is now working for the accelerated version ? I can not test it myself.

If it is working, it will be possible to close (at last !) the bug.


christop (administrator)

Ok at least with a nvidia card. Testing with ATI tomorrow and closing if everything is fine.


christop (administrator)

Is there any easy way to check which version of the code is used by an external program ?

Now that both version are working for me, I lost the possibility to do a visual inspection.


julien (administrator)

For an external program the version used will be the one defined in otbConfig.h.


christop (administrator)

I understand that this is how it is supposed to work.

However, it would be good if we had an easy way to check if this it really taken into account.

Adding something like:
    otbMsgDevMacro(<<"Using OTB_GL_USE_ACCEL: ON");
    otbMsgDevMacro(<<"Using OTB_GL_USE_ACCEL: OFF");
would be useful
(done in http://hg.orfeo-toolbox.org/OTB/rev/1720768152e6)


christop (administrator)

debug message shows that the option is taken into account. Everything looks fine.

-Issue History
Date Modified Username Field Change
2008-11-28 07:11 christop New Issue
2008-12-03 10:29 julien Note Added: 0000021
2008-12-03 10:29 julien Status new => feedback
2008-12-03 10:51 christop Note Added: 0000022
2008-12-03 11:04 julien Note Added: 0000023
2008-12-03 11:22 christop Note Added: 0000024
2008-12-03 15:09 julien Note Added: 0000025
2008-12-03 15:09 julien Note Edited: 0000025
2008-12-03 15:10 julien Note Edited: 0000025
2008-12-03 15:23 julien Note Added: 0000026
2008-12-03 16:25 julien Note Added: 0000027
2008-12-03 16:25 julien Status feedback => resolved
2008-12-03 16:25 julien Resolution open => fixed
2008-12-03 18:04 julien Note Added: 0000028
2008-12-03 18:04 julien Status resolved => closed
2008-12-04 03:40 christop Note Added: 0000029
2008-12-04 07:00 christop Note Added: 0000030
2008-12-04 07:00 christop Status closed => feedback
2008-12-04 07:00 christop Resolution fixed => reopened
2008-12-04 09:09 julien Note Added: 0000031
2008-12-04 09:42 julien Note Added: 0000032
2008-12-04 09:54 christop Note Added: 0000034
2008-12-04 10:49 julien Note Added: 0000036
2008-12-04 18:42 julien Note Added: 0000038
2008-12-08 10:00 julien Note Added: 0000040
2008-12-08 10:02 julien Status feedback => resolved
2008-12-08 11:03 christop Note Added: 0000041
2008-12-09 03:34 christop Note Added: 0000047
2008-12-09 09:42 julien Note Added: 0000048
2008-12-09 09:42 julien Status resolved => feedback
2008-12-09 10:18 christop Note Added: 0000049
2008-12-15 03:18 christop Note Added: 0000053
2008-12-15 03:18 christop Status feedback => resolved
2008-12-15 03:18 christop Resolution reopened => fixed
2008-12-15 03:18 christop Assigned To => christop
2008-12-15 11:01 christop Relationship added related to 0000055
2008-12-15 11:01 christop Status resolved => closed
+Issue History