Graphics Contest 2017, please vote now!

[J-G]

I just downloaded and tested Akira's code. I have no problem compiling the code. I currently have BGRABitmap 9.5.0.0 installed.

I've now updated to 9.5 but still have the same 8 errors and 3 warnings.

I installed BGRABitmap using Online Package Manager. Very easy and useful, you should try it. I believe you will fall in 'love' with it too.

Yes OPM is easy and useful  -  my emotions are not that easily stirred 

[Akira1364]

I've now updated to 9.5 but still have the same 8 errors and 3 warnings.

Just like the last issue you had, this one definitely has zero to do with BGRABitmap or any other package... not sure why that's your first assumption? TStringArray is nothing more than an alias for "array of string", defined in "syshelph.inc". So presumably your FPC installation has a version of that file that predates the introduction of the type.

That being said, literally all you should need to do to fix it is:

At line 243 of frmMain.pas, change it from this:

Code: Pascal  [Select][+][-]

1. SeparatedLine: TStringArray;

to this:

Code: Pascal  [Select][+][-]

1. SeparatedLine: array of String;

Edit: I'd also still like clarification on whether or not the GTK2 version of TSaveDialog is actually supposed to automatically append the filter extensions to filenames in the manner the Windows implementation does... anyone?

[J-G]

I've now updated to 9.5 but still have the same 8 errors and 3 warnings.

Just like the last issue you had, this one definitely has zero to do with BGRABitmap or any other package... not sure why that's your first assumption?

I'm not sure if it was lainz or handoko that first suggested that it might be the V9.2.1 versus V 9.5 issue - I just took that suggestion on board. I could well be the fact that I'm using Laz 1.6.0 and FPC 3.0.0  but I would have thought that since they are still the latest 'stable' versions they ought to be supported.
Perhaps it would help understanding if I mentioned that I'm just reporting what I find as I spend a few minutes checking the forum while I'm busy with other 'life' issues rather than evaluating the code trying to understand what's going on

TStringArray is nothing more than an alias for "array of string", defined in "syshelph.inc". So presumably your FPC installation has a version of that file that predates the introduction of the type.

That being said, literally all you should need to do to fix it is:

At line 243 of frmMain.pas, change it from this:

Code: Pascal  [Select][+][-]

1. SeparatedLine: TStringArray;

to this:

Code: Pascal  [Select][+][-]

1. SeparatedLine: array of String;

Done that, and yes, 6 of the 8 errors are gone along with the 3 warnings, leaving line 233 pos 108  ---  '.ToString'  with is not a component of '.Box.ItemIndex' apparently - and line 283 pos 42 ---  '.Split([',']' not being a component of 'LoadList.Strings[ I ]'.

[Akira1364]

Done that, and yes, 6 of the 8 errors are gone along with the 3 warnings, leaving line 233 pos 108  ---  '.ToString'  with is not a component of '.Box.ItemIndex' apparently - and line 283 pos 42 ---  '.Split([',']' not being a component of 'LoadList.Strings[ I ]'.

Strange. That's again related directly to the syshelph.inc file. It seems like the compiler isn't recognizing the string helper type, for some reason (which as far as I know should be perfectly functional in FPC 3.0.0)..

You could first simply try adding

Code: Pascal  [Select][+][-]

1. {$modeswitch TypeHelpers}

at the top of the form underneath the mode ObjFPC declaration, and see if that helps. If that doesn't work, try putting SysUtils at the very end of the list of "uses". (As well as at the very beginning, perhaps.)

[J-G]

Thanks Akira,  I've tried all those suggestions but still get the 2 errors. Just in case I've mis-understood your excellent instructions, here is the new heading to frmMain :

Code: Pascal  [Select][+][-]

1. unit frmMain;
2.  
3. {$mode objfpc}{$H+}
4. {$modeswitch TypeHelpers}
5.  
6. interface
7.  
8. uses
9.   SysUtils,
10.   {$IFDEF WINDOWS}
11.   Windows,
12.   {$ELSE}
13.   LCLIntf,
14.   {$ENDIF}
15.   Classes, Forms, Controls, Graphics,
16.   Dialogs, Buttons, StdCtrls, ComCtrls,
17.   ExtDlgs, ExtCtrls, Menus, BGRABitmapTypes,
18.   BGRABitmap, GL, OpenGLContext, uniGraphics,
19.   SysUtils;
20.  

I also tried with SysUtils only at the end.

[Akira1364]

Well, the code you've posted there wouldn't compile as it includes SysUtils twice. What I meant was try it at the very beginning and very end separately.

Edit: Just took a look, it seems the RTL type helpers were introduced in 3.0.2, so they're simply not going to exist in your sources. I'll see if I can throw together some alternate implementations that don't use them for the relevant methods... although I would also suggest you consider moving up to at least 3.0.2 generally, as there's quite a few benefits/useful additions.

Edit 2: Ok, just uploaded a new set of project files. There's now conditionally-compiled non-type-helper implementations of the string handling stuff for FPC versions less than 3.0.2. Here's the link:
https://forum.lazarus.freepascal.org/index.php/topic,35313.msg255447.html#msg255447

[J-G]

Success !!  
Well  -  I've compiled it and haven't (yet) broken it with 6 images

I did have to apply the previous corrections (ModeSwitch & Array of String) but that was no real surprise.

A small niggle - using 'ribbon' (any direction) on the first image, there are two copies of the image in the ribbon and the second one moves forward.

Testing with a 40Mb CMYK  .TIF  (3780 x 5551 px), it never manages to show the thumbnail (after a two minute wait). An 80Mb .PNG (RGB) (8297 x 5290 px) image shows the thumbnail but the main image is blank.

Well, the code you've posted there wouldn't compile as it includes SysUtils twice. What I meant was try it at the very beginning and very end separately.

That was my original thought but your instruction "(As well as at the very beginning, perhaps.)"   I interpreted literally but now appreciate that you meant "OR at the very beginning"

[J-G]

I've now tested a number of large images and whilst none of them 'crash' the program, they either don't load as a thumbnail or are blank in the main window.

If anyone wants to test them on their system I've put a few on my web-site at www.crescentcomputing.co.uk/laz/handoko

Corrected !!  Thanks Handoko

[Handoko]

I managed to find out how to reproduce crash on Akira's version. It is 100% reproducible both running the code from IDE and from the binary directly. Tested using Lazarus 1.6.4 FPC 3.0.2 Gtk2 64-bit on Ubuntu Mate 16.10.

1. Download 3-4.tif provided by J-G, it is inside Set1
2. Run the program
3. Load that 3-4.tif
4. Repeat step #3, then the program will exit immediately

[J-G]

I managed to find out how to reproduce crash on Akira's version. It is 100% reproducible both running the code from IDE and from the binary directly. Tested using Lazarus 1.6.4 FPC 3.0.2 Gtk2 64-bit on Ubuntu Mate 16.10.

1. Download 3-4.tif provided by J-G, it is inside Set1
2. Run the program
3. Load that 3-4.tif
4. Repeat step #3, then the program will exit immediately

Most of the images in Set1 are 8 bit and 3-4 is the smallest at 444 bytes it is 300 dpi and 10 x 29 pixels.  I have similar images of music time signatures and none of them load.

On my system they simply don't appear in the thumbnail.

I've now put another file in Set1  -  Chi An.png  -  which loads as a thumbnail but is skipped over in the slide show. Again it is an 8 bit image but at 4800 dpi and 9351 x 4472 px.

@handoko  -  you'll have noticed that I've corrected my typo     one never checks ones own name !

[Akira1364]

I managed to find out how to reproduce crash on Akira's version. It is 100% reproducible both running the code from IDE and from the binary directly. Tested using Lazarus 1.6.4 FPC 3.0.2 Gtk2 64-bit on Ubuntu Mate 16.10.

1. Download 3-4.tif provided by J-G, it is inside Set1
2. Run the program
3. Load that 3-4.tif
4. Repeat step #3, then the program will exit immediately

I think this problem only exists on Linux (more specifically, under GTK2). I tried making a slideshow that was just 25 copies of "3-4.tif" in a row and had no issues. I also tried continually loading it into the same image slot over and over again, and nothing went wrong. (I'm using Windows 10 64-bit with trunk FPC/Lazarus, just to clarify again.) Are you able to compile the application with the Debug profile and attempt to backtrace where/why exactly it crashes for you?

As far as J-G's images overall, almost all of them work perfectly for me. The only two that didn't were "Falls of Dochart 1A.tif" and "Canova Tomb.tif", which I noticed were LZW compressed and had bit depths of 32, whereas all of the other TIFs on his website (compressed and not) had bit depths of 24. After opening them in IrfanView and resaving them without compression, they loaded in glSlideShow. So it seems that the LZW decompression routine in the FPReadTiff unit (used internally by both TBGRABitmap and TPicture for loading TIFFS) only works on files with an original bit depth of 24 or lower.

I've attached a screenshot of a few of the images (including "beach.png", "Chi An.png" and "3-4.tif") in the midst of a ribbon transition. (Yes, that is the CodeTyphon logo in the top left corner.. I've been maintaining versions of the project files for both it and Lazarus, but I started with CT so that was the icon left in the folder.)

Also, @J-G: what are the hardware specs of the computer you're building/running the application on?

[J-G]

I think this problem only exists on Linux.

The complete crash on second load probably - I don't get it on Windows - but I do get non-load and non-show errors with 8bit images and non-show on large 24bit images.

So it seems that the LZW decompression routine in the FPReadTiff unit (used internally by both TBGRABitmap and TPicture for loading TIFFS) only works on files with an original bit depth of 24 or lower.

Well at least that seems to be a result - I did think about LZW compression but since I use that as a matter of course and it hasn't been a problem in the past, ignored my thought!

It seems reasonable that - for this application - the FPReadTiff unit only handles 24bit since it is intended only for screen display (RGB) rather than print (CMYK).

Much of my graphic work has a destination in print so CMYK (32bit) is again a default state, reverting to RGB (24bit) for work which will only be shown on the web. The images I tried were selected at random with a 'nod' toward 'size' or 'resolution'.

Also, @J-G: what are the hardware specs of the computer you're building/running the application on?

M/b  -  ASUS M5A97LE
CPU -  AMD FX-6300 3.5GHz 6-core
RAM - 4Gb DDR3
Display - nVidia GeForce 9500 GT

[Handoko]

Are you able to compile the application with the Debug profile and attempt to backtrace where/why exactly it crashes for you?

Debug build mode did not help. I even turned all the checks on (io, range, overflow, stack, verify, assertion), it just exited immediately without any error/warning message. But if I remove LoadImageDialog (TOpenPictureDialog), add a TOpenDialog and rename it to LoadImageDialog, it can load 3-4.tiff several times without crash . So it is clear the problem is in TOpenPictureDialog.

I will try to get some computers for more intensive tests.

[Handoko]

I'm back with my test result.

Software: Lazarus 1.6.4 FPC 3.0.2 Linux64 cross compile to Win32
Source Codes: glSlideshow Handoko version and Akira (Debug mode) version
Hardware: Intel Core 2 Duo with integrated NVIDIA 7100 (drivers installed properly).
OS: WinXP Service Pack 3

Handoko Version

Most J-G images were able to load and can be seen as thumbnails on the buttons. But most them will crash the program if playing the animation. The images that cannot be loaded will show "LZW stream overrun" message.

If the program crash, I have to use Task Manager to kill it. In some rare cases I have to press reset button.

Akira Version

Some of the images (5) that cause crash on Handoko version, can be played correctly on Akira version.

If the image fails to load, nothing will happen (no crash). The program will still run correctly.

I found 2 bugs, always reproducible:  (see the attachment below)
- When exiting the program a memory error message will show up
- Viewport not update, when starting the program

Image Loading & Playing Capability

                             Handoko    Akira
                            Load Play  Load Play
- 3-4.tif                     ✔   ✔      ✔   ✘
- Beach.png                   ✔   ✘      ✔   ✘
- BSL Logo.tif                ✔   ✘      ✔   ✘
- Canova Tomb.tif             error      error
- Card Background.tif         ✔   ✘      ✔   ✔
- Chi An.png                  ✔   ✘      ✔   ✘
- Dullcisima.tif              ✔   ✘      ✔   ✔
- Falls of Dochart 1A.tif     error      error
- Horns-Solar.tif             error      error
- Inn at waterloo.tif         ✔   ✘      ✔   ✔
- Leuven Town Hall.tif        error      error
- Menin gate.tif              ✔   ✘      ✔   ✔
- Paul Sings Dullcisima.tif   error      error
- snowflake BW.png            ✔   ✔      ✔   ✔
- snowflake BW NonInt.png     ✔   ✔      ✔   ✔
- vonEssen.tif                ✔   ✘      ✔   ✔

[Akira1364]

The complete crash on second load probably - I don't get it on Windows - but I do get non-load and non-show errors with 8bit images and non-show on large 24bit images.

Yeah, I was referring specifically to Handoko's problem.

M/b  -  ASUS M5A97LE
CPU -  AMD FX-6300 3.5GHz 6-core
RAM - 4Gb DDR3
Display - nVidia GeForce 9500 GT

That is a rather uncommon setup... 6-core AMD Vishera CPU with a graphics card from 2008? That being said, as the GPU does have 1 GB video memory and you have 4 GB system memory, you should technically be more than able to load any of the larger images from the collection you provided. The reason you can't could be caused by anything from shaky driver support on 64-bit Windows 7 for the old GPU, to conflicts between the CPU/GPU/Motherboard setup. (The latter would be somewhat rare, although it's highly unlikely that the BIOS of your motherboard was designed with any expectation of a DDR2-era graphics card being installed, so there could be some kind of compatibility issue there.)

One thing I should clarify though is, are you building the application as a 32-bit or 64-bit executable? If you're building it 32-bit, I'd strongly recommend trying 64, as 64-bit GPU drivers running under 64-bit operating systems are not optimized for 32-bit applications and tend to have a higher number of issues/bugs while running them.

Debug build mode did not help. I even turned all the checks on (io, range, overflow, stack, verify, assertion), it just exited immediately without any error/warning message.

Were you actually running the debug version under GDB, though? If so, there should have been at least some indication in the "Debug output" window of Lazarus as to where things failed...

I'm back with my test result.
Software: Lazarus 1.6.4 FPC 3.0.2 Linux64 cross compile to Win32
Source Codes: glSlideshow Handoko version and Akira (Debug mode) version
Hardware: Intel Core 2 Duo with integrated NVIDIA 7100 (drivers installed properly).
OS: WinXP Service Pack 3

The Nvidia 7100 only has 128 megabytes of video memory. You were also compiling the application as 32-bit and running it on a 32-bit operating system, meaning the application itself could only make use of a maximum 2 gigabytes system RAM. (As in, not enough to allow the graphics card to do any kind of sharing of the system memory when it begins to run out of video memory, which is a feature of some GPUs. I'm unsure if the NVidia 7100 is one of them, though.) Not that the application would generally need anywhere close to 2 gigabytes overall, it's just that it almost certainly wouldn't be deemed as enough "extra" system memory by the GPU driver to consider the sharing operation safe.

Those are, overall, what I would call "expected results." It's not reasonable to assume that the hardware you outlined there should be able to load images that are as large and high-DPI as the ones J-G provided (as they pretty much all take up more than 128 megabytes of video memory when uncompressed and uploaded as OpenGL textures.) Again, I tested all of the images on J-Gs website, and the only two that didn't work for me were "Falls of Dochart 1A.tif" and "Canova Tomb.tif" (because of the limitations of the FPReadTiff unit I described in my last post).

If the image fails to load, nothing will happen (no crash). The program will still run correctly.

That is very much on purpose/exactly how I wrote it to behave.

- When exiting the program a memory error message will show up

The heaptrc window is not an error. It's just the window that always shows when you close any application built with the heaptrc memory logging unit activated. On top of that the window in your screenshot actually confirms what I already knew, which is that there are no memory leaks in my version (not that anyone was assuming a leak was specifically the cause of any issues).

- Viewport not update, when starting the program

Not sure what you mean. When you're first starting the program, there's nothing to show as you haven't loaded any images yet, so it's blank. If you're referring to the garbled window in your second screenshot, that's almost certainly some kind of hardware issue/Windows XP issue. It should just be entirely white. Something seems to have gone wrong with the character encoding at some point in your cross-compilation process as well, as there's a bunch of characters displaying as squares when they should be actual letters.

Lastly, I was really far more interested in the issues you were having with my version running on your native Ubuntu installation, as any bugs that might be found there aren't ones I would come across myself running it on Windows. I'm unsure as to why exactly you thought cross compiling from Linux to Windows XP of all things would be useful or relevant...