Application is a tomography processing program.
IDE for development is XE5 (was earlier D2007).
It uses GLScene 0.8.2 due to conversion problems.
In the processing a main loop is performed to refine the data.
Every time the main loop is iterating a Render call is made to show
the new data set.

What happens is this:
When I use the Delphi 2007 compiled application all I see during
processing is updates of the screen images a few seconds apart.
But when I run the XE5 compiled version the screen flickers madly and
the total processing time is increased from 7 seconds to 40 minutes! A
factor of over x300!!!!

It seems like the screen is repainted for each iteration in some inner
loop and that the repaint causes the extra time. Cannot understand why
this happens though. Not shown in the logfile.

I have placed logging calls with millisecond timing around the Render
call and I see that these calls are made exactly as expected, once per
mainloop iteration. The render itself takes about 30 ms.

_STRANGE DISCOVERY:_
While testing this I happened to minimize the application window and
then when I restored it a few seconds later it was ready and done!
So I made a test:
- Click the process start button
- Immediately minimize the application
- Look at the logfile

Turns out that I can see in the logfile that the processing time is
now back to the expected 7 seconds.

So if the application is minimized it no longer processes the graphics
repaint whatever at this insane pace.

Note: It did not help to cover the application window by another
program so that it was invisible, it still does its thing and no time
is saved. Must be minimized...

Any ideas where to even start looking for such a thing.
D2007<->XE5 incompatibility?

Bo,

Don't you just LOVE 'puters?  ;-)  

-- 

   Q 

1.19.1.372  (Q's Broken Toolbar.)

On Wed, 21 Jan 2015 13:22:56 -0800, Quentin Correll
 wrote:

>Bo,
>
>| I really wonder what kind of magic Polygon/PolyLine does for it to
>| erase the containing image?
>
>Probably just overwrites the canvas with the background color. 

That is what the helpfile says for Polygon, but it also says that
PolyLine does not do this. But the result is the same for both...

And to top it off, this was not how it worked (using Polygon) when the
program (compiled in D2007) executed on Windows XP and also on a fresh
Windows 7 SP1 (both 32 and 64 bit). In all of those cases the rendered
image stayed on screen.
Then along came a Windows Update for Win7 and suddenly the rendered
image was gone when exactly the same binary was used....

So I am wondering what change a Win7 update could bring to make this
happen?

Anyway, I spent about 6+ weeks a year ago to try and find the reason
for this behavior thinking it was something that was caused by the old
version of GLScene we were using. Could never get it to work properly
at that time with a newer GLScene so I gave up.

Was not a GLScene problem after all, rather a strange difference
between PolyLine/Polygon and individual line drawing.

Bo,

| I really wonder what kind of magic Polygon/PolyLine does for it to
| erase the containing image?

Probably just overwrites the canvas with the background color. 

-- 

   Q 

1.19.1.372  (Q's Broken Toolbar.)

On Wed, 21 Jan 2015 11:14:15 -0800, Bo Berglund
 wrote:

Now I found out what is causing the problem where the rendered section
disappears when a drawing grid is placed on the image!
This is the original code that causes the rendered image to disappear:
{code}
  // Draw outer boundary first
  gap := Round(0.005 * min(xx, yy));
  x1 := gap;
  y1 := gap;
  x2 := xx - gap;
  y2 := yy - gap;
  with cnvs do
  begin
    Pen.Width := Round(2*gfHeightScaleFactor);
    Polygon([Point(x1,y1),Point(x1,y2),Point(x2,y2),Point(x2,y1)]);
  end;
{code}
By replacing the plotting code with the following the rendered section
image does not disappear anymore:
{code}
  with cnvs do
  begin
    Pen.Width := Round(2*gfHeightScaleFactor);
    MoveTo(x1, y1);
    LineTo(x1, y2);
    LineTo(x2, y2);
    LineTo(x2, y1);
    LineTo(x1, y1);
  end;
{code}

The only difference is that the Polygon() call is no longer executed,
replaced by simple LineTo calls and it all works again!
This part of the code places a rectangular border around the plotting
area so a nice outline is produced.

In tghe help I read that Polygon will end by filling the drawn shape
with the Brush color and that in order not to fill one can use
PolyLine instead, but tha does not work! PolyLine also erases the
rendered image!
Only LineTo calls preserves the image, so that is what I will use now.

I really wonder what kind of magic Polygon/PolyLine does for it to
erase the containing image?

On Wed, 21 Jan 2015 10:04:05 -0800, David Millington <> wrote:

>> {quote:title=Bo Berglund wrote:}{quote}
>> Instead I will start looking at the processing chain in order to find
>> another bug that showed up after a Windows Update update was applied
>> to Win7....
>
>I have no idea about that one.  But good luck!
I did not expect it really...
But I just wanted to show another example of "surprises" one can get.

Anyway I have now gone through the code executing below tyhe button
that commands drawing of the information grid and added logging on
entry and exit of all called functions, just to see where the
difference is in processing with and without the grid.
I could think of no other way to find out what is going on....

> {quote:title=Bo Berglund wrote:}{quote}
> Instead I will start looking at the processing chain in order to find
> another bug that showed up after a Windows Update update was applied
> to Win7....

I have no idea about that one.  But good luck!

On Wed, 21 Jan 2015 05:16:34 -0800, David Millington <> wrote:

>Rendering should render what is /already/ calculated, not cause calculations.  
>The approach I'd take to this is to change the RenderColorImagePseudo so it 
>renders the data it has.  Then cause the calculation elsewhere (and only 
>calculate it if it truly has changed.)  Then once the new data is present, 
>Invalidate() to repaint - which again will just paint what's there, it's 
>just that there's new stuff there now.
>
>The other reason I write that is that while double-buffering might prevent 
>all this, it's probably only because the view doesn't need to re-render 
>when it's double buffered. It's not a safe solution, because there are 
>situations where double-buffering may not work or may not prevent rendering 
>calls.  Remote Desktop or Citrix is a possible problem, for example.  
>A more likely one might be problems using non-themed Windows, which removes 
>Aero optimisations and relies solely on Delphi's double buffering, whi
>ch may not have an effect (?) for a GL context.
>
>That said having DoubleBuffered on probably results in smoother graphics 
>anyway! I'd just recommend you solve the problem so it works ok when it's 
>off, before you turn it on.
>
Hi David,
I fully agree with you, but that said I have to supply a working
application to the translators so they can test the new language file
translations we are preparing. So stopping the flicker this way
suffices for now. I won't release it to customers just yet.

Instead I will start looking at the processing chain in order to find
another bug that showed up after a Windows Update update was applied
to Win7.
What happens is that when a function is called to plot a drawing grid
with a header containing project data on top of the rendered
tomographic section, the actual section image disappears from view.
This only happens for screen targets, not for the printer canvas or an
image export.
And on a newly installed Windows7 SP1 it also does not happen, but as
soon as one lets Windows Update do its thing the display problem
appears....
It is as if the image and drawing grids are on separate buffers
instead of on the same.
Very strange problem that has bugged me for 18 months now.

So I will have to go deeper into the code anyway to handle this.
And it is not written as OO, looks more like spaghetti.....

> {quote:title=Bo Berglund wrote:}{quote}
> I put in logging into the code at various places to identify the
> culprit. And I caught what was happening! There is a function named
> RenderColorImagePseudo, which appeared thousands of times in the
> logfile after I put in the log statement and did a test run with
> flickering.
> And this function does a lot of stuff, calculates the triangular mesh
> and fills the triangles with value dependent colors etc. LOTs of work!
> It should not be called from whatever is calling it in some event
> code!
> But it stopped when I enabled DoubleBuffering.

That's a good discovery!

> Still I need to find out what the original developer did to cause this
> behaviour....

Rendering should render what is /already/ calculated, not cause calculations.  The approach I'd take to this is to change the RenderColorImagePseudo so it renders the data it has.  Then cause the calculation elsewhere (and only calculate it if it truly has changed.)  Then once the new data is present, Invalidate() to repaint - which again will just paint what's there, it's just that there's new stuff there now.

The other reason I write that is that while double-buffering might prevent all this, it's probably only because the view doesn't need to re-render when it's double buffered. It's not a safe solution, because there are situations where double-buffering may not work or may not prevent rendering calls.  Remote Desktop or Citrix is a possible problem, for example.  A more likely one might be problems using non-themed Windows, which removes Aero optimisations and relies solely on Delphi's double buffering, whi
ch may not have an effect (?) for a GL context.

That said having DoubleBuffered on probably results in smoother graphics anyway! I'd just recommend you solve the problem so it works ok when it's off, before you turn it on.

Cheers,

David

On Wed, 21 Jan 2015 01:52:39 -0800, David Millington <> wrote:

>Hi Bo,
>
>A few things:
>
>1. Huge delay (-> 40 minutes.)
>One thing to check is if processing is caused by screen painting.  
>Generally, screen painting should paint only the data that is already 
>present and known about - it should not trigger a calculation or request.  
>But it's quite common not to do this and to have the paint code cause 
>work to be done.
>
>So I'd look into what it's doing that is taking so long.
I put in logging into the code at various places to identify the
culprit. And I caught what was happening! There is a function named
RenderColorImagePseudo, which appeared thousands of times in the
logfile after I put in the log statement and did a test run with
flickering.
And this function does a lot of stuff, calculates the triangular mesh
and fills the triangles with value dependent colors etc. LOTs of work!
It should not be called from whatever is calling it in some event
code!
But it stopped when I enabled DoubleBuffering.
Still I need to find out what the original developer did to cause this
behaviour....
>
>2. DoubleBuffered toolbar problems
>I can't remember if toolbars have problems specifically, but on some older 
>versions of Delphi I know things didn't always render correctly.  
>XE5 is later than I would have expected for this, but...
I made an XE5 VCL test project only containing two TToolbar at the top
of the main form. Then when I set the Form.DoubleBuffered=true and
made a test execution the toolbars did come out all black!
So it has nothing to do with the application I am working on, instead
it is inherent in these components in XE5. Can't say from when though.

When I looked further I found that the toolbars had a property
Transparent which was set true by default. When I changed this to
false the toolbars stopped being black!
So that is what I have done in the main application too and now I can
use DoubleBuffer and still have the toolbars look OK.
>
>One approach might be to not double buffer the entire form, but just the 
>control the GLScene control is on - eg, make a TPanel, place that where your 
>GLScene control is, and put the GLScene control on it. Then double-buffer the 
>panel only.

Good idea, I will try this so that the double buffering is only
applied to the GLSceneViewer itself.
- And I have done this now and everything seems to work OK, still
there are calls that I have to trace down, but that is a different
issue.

>It's quite possible the GLScene control has a DoubleBuffered property itself, 
>in which case try turning only that one on, too.
It does, but it sets this by itself after checking what Windows is
capable of...