After more testing, the 64-bit seems to be the fix. Works in Win10 and Win11. There must be something in the change in Win11 as you mentioned. After finding this out, I made sure other code was compiling as 64-bit. Doing this on on program fixed some anomalous behavior on just one old laptop, Win10 but old CPU, system reports this as I5-5200U. I wondered if there was something specific about this processor that would give infinities for one computation that other systems would not. Anyway, that seems to have gone away with the 64-bit version.

Thanks,

Rod

Sorry for the long delay in my response.  I'm glad that it seems to work with a 64-bit target.  There may have been changes to how the Windows 32-bit system works under Windows 11 64-bit, but I seriously doubt it would be the cause of what you've described.  So I remain a bit baffled.  However, it is, at this point, practically impossible to obtain 32-bit Windows through any legitimate means, so I think sticking with just a 64-bit executable is safe.

Simply Fortran will repopulate the flags with those libraries.  The "32" at the end of the libraries does not imply 32-bit anymore.  Microsoft decided to keep the naming convention because, even when compiling a 64-bit executable, you're using what Microsoft was calling the "Win32 API" for a time.  I don't believe they still call it the "Win32 API."  Now it is the "Windows API" maybe?  But the library names held on to their 32-bit filenames despite the progress.

I think I fixed my issue, well perhaps fixed it. I still have to test other things but so far so good.

So I while checking CPU usage on task manager, I saw that the CPU usage was low even while slow plotting circles. However, while looking at task manager, I noted that the executable was still 32-bit. I created a new project to make a  64-bit executable and recompiled. This 64-bit executable works the same as the 32-bit did on Win10. I have briefly test the 64-bit on WIN10 and WIN11 and behaviors are consistent. More testing to follow but things look good for now.  Any ideas on why this works in 64-bit and not in 32-bit?

Question, my original 32-bit project has all this as linker options.
-lappgraphics -lgdi32 -lcomdlg32 -lcomctl32 -luuid -loleaut32 -lole32

I only included the first one in the new project and the project compiles and runs fine. Do I need anything else as compiler or linker directives other than -lappgraphics? Edit- I just noticed that the project automatically repopulated the linker strings as above.

Thanks,
Rod.

I changed the circle draw to a pixel only draw and the slow down still happens. That was a good test, as now it seems to be tied with some other event or property of the code after the check box is checked. In addition, it still behaves the same after the first loop of points to be plotted; it speeds up to normal, just as before.

I scanned the code for things that might change after the check box is checked but I don't see anything obvious.

Rod

I understand what you're drawing, but I'm not sure why things would slow down on Windows 11 still.  Could you try one thing?  What if, instead of circles, you continued just plotting single pixels at the circle center?  I'm just trying to narrow down the cause of the slowdown without access to the code.  Does it run at "full speed" if you make that change?

I don't think (at least from what I read) that setrefeshing will help me. Here is why I think that.

The program has two plotting viewports, left is the X-Y plane, right is Z-Y plane. Plotted objects, either a single pixel or circle are alternated between viewports. So what happens is if a particle position is determined to be plotted for the current time period then plottening is enabled for both viewports. Then if there is already a position from the last plot cycle already in the viewport, that position point is overwritten with a corresponding black equivalent object. Then the new position is plotted in that viewport. The program switches to the other viewport and the same action is completed there. In this way I kind of animate the temporal changes in each of the two viewports.

So from this, i am constantly swiching between the viewports. As such I don't think I want to use the setrefreshing call.

Does that make sense?

Rod

Sorry, I wasn't saying it's a "display" problem, but, rather, an issue with Microsoft's implementation of fractional scaling and its interaction with Windows GDI primitives.  Apparently Windows 11 did change some behind-the-scenes aspects of the GDI when running under fractional scaling that has caused some slowdowns.  It doesn't sound like they are as bad as you're reporting, though.  The issue I was trying to nail down was if the problem was caused by fractional scaling.

You could see speed improvements by using double-buffering for the circle-drawing operations or, alternatively, experiment with calling call setrefreshing(.FALSE.) while you're drawing all the circles.  Those changes would avoid the automatic window refreshes requested after each and every circle being drawn.

I don't think the monitor has anything to do with it. Reasoning is that as noted above, when plotting circles, if I wait for all the particles in the viewport to plot, then subsequent loops plotting is normal speed/fast. It is the first time having to plot circles that everything slows down. It has this behavior on all machines that I use. 

Also, I have 6 machines that I remote desktop into that run the program. Two are Win11 and 4 are Win10. All have different monitors or no permanent monitor and all behave the same.

My main workstation does have a large monitor using 3440x1440 pixels. It too behaves the same as all the other RD systems. I converted this system from Win10 to Win11 earlier this year and the problem began happening on it. One system I build last year with Win11, had the issue from day one and it is without a fixed monitor; I only RD into it. My other Win11 was converted from Win10 to Win11 last fall. It is a MS Surface 7.

All remote desktop sessions are constrained to be ~1600x1000 sessions. Only the Surface uses some sort of scaling for its display.

I just have too many different displays and resolutions that have the exact same behaviors to expect it to be a display problem.

Rod

Does the Windows 11 system have a different monitor than your Windows 10 computer?  Does the Windows 11 machine perhaps have a high DPI?  The GDI (which AppGraphics uses for drawing) slows down considerably on scaled desktops, and circles (actually ellipses) will slow down particularly if the screen is using any fractional scaling.  That could be one source of the difference between 10 -> 11.  Ellipses are costly to draw.

Plotting single pixels is slow? Right now I have my program plotting over 7000 pixels in two windows and it takes about a second (about 14,000 pixels total). The plot cycle is repeated over and over as long as the program is open. So from my perspective, that isn't too slow.

Plotting single pixels is not the problem. The problem is transitioning from plotting pixels to circles that things slow down. Then plotting a single particle position with a circle can take 1 second; that is too long. This isn't a problem with the same code running on WIn10 or lower. It breaks in Win11.

I really would like a fix for this behavior.

Rod

To reiterate what does happen is that if I set the plot size option while the scale requires just to plot a single pixel, then things are fine and all points within plot window plot very quickly. Now if I zoom into a point where the scale is small enough plot the actual particle size, then plotting slows down to a crawl, where it might take a couple seconds for each particle position to be plotted.

Another test case is that if I first zoom in the a scale size that is small enough to plot sizes,then check the plot size box, the same with happen where particle positions will take many seconds.

How many points are you plotting, incidentally, when you see this slowdown? 

I will point out that plotting single pixels is slow.  The process is a bit more complex than people might realize.  When you call putpixel, the following occurs:

1. Look up window data from the program's list of known open windows
2. From the window data, retrieve and lock the appropriate Windows device context
3. Set the single pixel
4. Release the device context
5. Issue a redraw request for the rectangle containing the pixel (so, a 1 pixel by 1 pixel rectangle) to the Windows message loop

So drawing pixels is not particularly efficient.  It could absolutely be improved.  However, if you're drawing hundreds of thousands of pixels, drawing slows down quite a bit.  Some of that overhead is AppGraphics' fault in an effort to be as general as possible.

The latest version of the code doesn't cause the mouse pointer to behave erratically. That might have been maybe some other weird interaction with a busy system? Not sure...

To reiterate what does happen is that if I set the plot size option while the scale requires just to plot a single pixel, then things are fine and all points within plot window plot very quickly. Now if I zoom into a point where the scale is small enough plot the actual particle size, then plotting slows down to a crawl, where it might take a couple seconds for each particle position to be plotted.

Another test case is that if I first zoom in the a scale size that is small enough to plot sizes,then check the plot size box, the same with happen where particle positions will take many seconds.

Now all that said and it is still true with following caveat. As I write this I am retesting and something that I never have seen because of impatience is that, if I wait long enough, not sure how long, I think only one loop cycle to plot all the points, the plotting speed is as it should be, fast. Subsequent checks and unchecks of the plot size option work as "normal" with quick plotting speeds. The other option that uses plotting circles for particle size is the "Plot PPV" option. Once the other option works, then PPV option behaves too. Note too that the plot loop will only plot particles whose position is within the cube defined by the scale time. As such, zoomed tightly, there  fewer particles in the plotting cube so it completes the loop more quickly than when there are more particles in the cube.

So, as it turns out, I have a work around until this gets figured out.
Thanks,
Rod

I suspect there is a bug in the text alignment routines.  I'm trying to sort out how text alignment is being handled since it isn't particularly straightforward. 

I'm still looking into the checkbox issues causing the mouse problems.  It doesn't appear that your code does anything wrong, so I suspect we're getting stuck in some sort of unintended infinite loop.

The code for what is happening between the correct text placement and incorrect placement was posted previously. I tested the settextjustify and noticed that the first three outtext calls had no justification set for them but later ones do.

Putting in a settextjustify before the first three outtext changes lots. However, here is what I changed it too for the first three and the next couple and that puts things in the right place.

call settextjustify(LEFT_TEXT,TOP_TEXT)

Using this on WIN10 does not break the new positioning too.

I was using:
call settextjustify(LEFT_TEXT,CENTER_TEXT)

but that causes the problem.

I changed all instances (where it made sense) of CENTER_TEXT to TOP_TEXT and now all written text to the control viewport is in the appropriate place.

There is still something off about the information viewport. I need to
settextjustify(LEFT_TEXT,BOTTOM_TEXT)
then
settextjustify(LEFT_TEXT,TOP_TEXT)
just before writing to the informational viewport.

for that text to show all three lines of text (no specific offset needed). This again isn't broken when testing on Win10.

With those changes, I can get all the text back where they originally were.
Also, that fixed the placement of text in the density and phase space plots.

I really need to get a fix for particle size plot feature.

Rod

From what I can tell, the font for the R3.41 is the same as the previous version, However, other than the first three outtextxy calls, all the ones that follow are shifted up by about 5-6 pixels.

This tidbit might be the most interesting hint as to what's happening.  What happens between the first 3 calls to outtextxy and the remaining calls where the text is shifted?  Are you performing any other drawing, changing the text justification, or creating a plot?

You might try calling settextjustify with the vertical component set to TOP_TEXT to see if some justification setting is off and gets reset properly.  I'm not saying that there isn't a bug, just that it might show an improvement.  If it does fix things, then we can start to look for where the justification is being modified.

I'm still looking at the checkbox callback issue.  I didn't see anything obvious in simple tests, but there may be a Windows event loop issue that gets out of hand.