Well at least you've found a reason 
and many thanks for taking the trouble to do the research. Though it doesn't address the fact that the 3-4.tif image at 10 x 29 px won't load even the thumbnail ????
No problem!
As far as "3-4.tif" specifically, it definitely has nothing to do with OpenGL if the TBitBtn thumbnail isn't even showing for you, as the procedure is exited immediately if the initial TBGRABitmap fails to load meaning there's no OpenGL texture being created at all.
Again, I was able to use 3-4.tif myself with no issues (as shown in the screenshot I posted before), so the application code as currently written definitely does exactly what it's supposed to. I imagine the problem in your case likely has something to do with an internal difference somewhere in the sources of either the FPC RTL or the Lazarus LCL between the versions you're using and more recent ones.
What I think I might do is alter the loading routine a little bit so that it at least shows a message box containing information about what went wrong in the event of an error (while still
not raising a "fatal" exception, as I think it's silly to make a user think they need to close the application just because one image fails to load, and there's no good reason to do so anyways as the code is already written to still properly free any memory allocated by the procedure in that case.)
For now though, you could simply try building the Debug profile of the Lazarus project, and running the application under GDB through Lazarus to see if you can get any more specific information about the problem.
GTX 1050 Ti cards with 4Gb are in the range of £170 - £210 - I would of course not pay that much because I buy at 'trade' anyway - but the cost of a new card is not the only consideration.
Oh yeah, I know it's not exactly going to be a direct price conversion. I was just giving a rough estimate, and the card was just one example... you could even go as far back as something from the 700 series (circa 2013 or so) and be in great shape. Although if you're able to get everything for trade/vendor costs or close to them anyways, I would think you could have your pick of most of what's currently available without breaking the bank.
First - for my real needs, what I have does the job very well, all the images I've put forward display in the two main programs that I use.
I don't doubt that at all, but it's important to keep in mind the difference between software rendering and hardware rendering, and what the use cases for each of them are.
I'm assuming the programs you're referencing here are CorelDraw and Photoshop, which you mentioned previously, both of which do everything at the software level (meaning using system RAM and your CPU, not the graphics card). This makes perfect sense as neither of them have any need to be able to render complex animations at high speed, and for the most part are displaying entirely static windows, so they make use of the (higher in essentially all cases than the GPU) amount of system RAM to get even the largest images on the screen for editing. As such, your graphics card while using those applications is not doing much more than driving the output to your monitor.
An application like glSlideShow, however, would simply not be able to smoothly render the rapidly changing animated frames at an acceptable speed if it was implemented at the software level. (As in, for example, if the rendering itself was done via BGRABitmaps built in drawing methods as opposed to just using BGRABitmap as a way to get images uploaded to the graphics card for use with OpenGL.)
This would of course be due to the latency caused by storing images in system memory versus storing them directly in graphics card memory, and by the fact that the result of the (less optimized, non-parallel) CPU-based drawing commands would just be getting interpreted for display at a raw pixel level by the graphics card (instead of being directly executed, generally in parallel,
on the graphics card).
The significant boost in speed you get from hardware APIs like OpenGL does come with certain manufacturer-imposed limitations, however (such as the GL_MAX_TEXTURE_SIZE limit you encountered) most of which exist for reasons related to memory management concerns at the GPU level.
You may have already known some or all of that (or not), but I thought I'd post it anyways for anyone else reading the thread who might not understand the differences, haha.
And of course the two cards with 2 DVI-D connectors can't be converted to VGA anyway.
Not sure what you mean here. There's a variety of "active conversion" DVI-D to VGA adapter cables and dongles available from various manufacturers. They're used quite commonly in a lot of office environments to connect to analog VGA-only projectors.
Poll
