2020-08-05 11:04 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000028OTB-libGeneralpublic2008-12-15 11:02
Reporterchristop 
Assigned Tochristop 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Summary0000028: OTB_GL_USE_ACCEL and external OTB programs
DescriptionThe solution introduced at:
http://hg.orfeo-toolbox.org/OTB/rev/7fd18e37aa99
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

-Relationships
related to 0000055closedmickael Altenate viewer don't use OTB_GL_USE_ACCEL 
+Relationships

-Notes

~0000021

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 ?

~0000022

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.

~0000023

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.

~0000024

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.

~0000025

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).

~0000026

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".

~0000027

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).

~0000028

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.

~0000029

christop (administrator)

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

~0000030

christop (administrator)

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

~0000031

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 ?

~0000032

julien (administrator)

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

~0000034

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:
-RebuildOpenGlBuffer()
-RebuildFlippedOpenGlBuffer()
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?

~0000036

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.

~0000038

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.

~0000040

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.

~0000041

christop (administrator)

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

~0000047

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.

~0000048

julien (administrator)

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

~0000049

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:
#ifdef OTB_GL_USE_ACCEL
    otbMsgDevMacro(<<"Using OTB_GL_USE_ACCEL: ON");
#else
    otbMsgDevMacro(<<"Using OTB_GL_USE_ACCEL: OFF");
#endif
would be useful
(done in http://hg.orfeo-toolbox.org/OTB/rev/1720768152e6)

~0000053

christop (administrator)

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

-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