* * *

Author Topic: TGIFViewer component  (Read 4719 times)

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
TGIFViewer component
« on: June 23, 2018, 11:23:22 pm »
Hi, to all

I'm proud to share with you my component TGIFViewer

TGIFViewer is a visual component for displaying animations at GIF (Graphic Interchange Format) with Free Pascal and Lazarus

Compatibility: Windows, Linux and MacOS

Capabilities of TGIFViewer:

  • Loading from a stream, file, or resource (LoadFromStream, LoadFromFile, LoadFromResource functions)
  • Extraction of raw images (** DisplayRawFrame function)
  • Extraction of pre-calculated images from the animation (DisplayFrame function)
  • Display with or without transparency (Transparent)
  • Silent management of some badly encoded data to allow the display of images without disturbing the user
  • Error handling for poorly compressed files '(OnLoadError)
  • Center (Center), Resize (Stretch) the display
  • Dimension of the automatic component according to the image (AutoSize)
  • Evident when playing, stopping or pausing the animation (OnStart, OnPause, OnStop)
  • Access to GIF images and information via the Frames.Items property

Also contains 2 units:

  • uFastBitmap: Class for handling 32-bit bitmap in RGBA or BGRA format depending on the OS
  • TypesHelpers: Classes that add useful functions to the data type (Byte, integer, string, double, TDateTime ...) functions can be accessed directly through the completion of the code under Lazarus.

You can download GIF-ImageTestSuite : https://github.com/jdelauney/GIF-ImageTestSuite for testing with several differently encoded GIFs

Installation:
  • In Lazarus go to the 'Package' menu and select 'Open a package file (' .lpk ')
  • Select gifviewer_pkg.lpk from the Package folder
  • Click on the 'Compile' button
  • Click on the 'Use' button and then 'Install'

The TGIFViewer component will be installed in the Beanz Extra section

Note:
The GifView demo application of the Demos folder does not require the installation of the component in the IDE to work.

License: MPL
© ️ 2018 J.Delauney (BeanzMaster)

Download from Github : https://github.com/jdelauney/TGIFViewer


French topic here : https://www.developpez.net/forums/d1867467/autres-langages/pascal/lazarus/annonce-composant-tgifviewer/

Best regards

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #1 on: June 24, 2018, 04:33:53 am »
Some demonstrating videos

Test under Windows 10 : https://www.youtube.com/watch?v=9KsZ70kVy4s

Test under Linux           : https://www.youtube.com/watch?v=Ci5i3o5XZdY

Test under MacOS         : https://www.youtube.com/watch?v=8f1Ft959lpk


Alextp

  • Hero Member
  • *****
  • Posts: 700
    • UVviewsoft
Re: TGIFViewer component
« Reply #2 on: June 24, 2018, 09:55:56 am »
I have added few issues in Github, pls see.

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #3 on: June 24, 2018, 01:44:38 pm »
Hi, Thanks Alextp for feed back. I answered to the issues ;)

I've just updated code. I've corrected some minors bugs from french user's feed back

GetMem

  • Hero Member
  • *****
  • Posts: 3207
Re: TGIFViewer component
« Reply #4 on: June 24, 2018, 01:57:29 pm »
Hi BeanzMaster,

When the component is stable enough let me know so I can add it to OPM.

PS: I ran a few test and works fine.

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #5 on: June 24, 2018, 09:16:10 pm »
New update

Following Alextp recommandation :

(see updated GIFView demo)
  • Begin translate french comments to english in interface parts
  • Made some minors change

Translate in action: https://www.youtube.com/watch?v=tRI7Kw2RTw8

Hi BeanzMaster,

When the component is stable enough let me know so I can add it to OPM.

PS: I ran a few test and works fine.

Hi GetMem, Thanks for testing it. And thanks for add it to OPM.  It's enough stable at this stage .But Take your time and have good hollidays before   ;)

Cheers

wp

  • Hero Member
  • *****
  • Posts: 5053
Re: TGIFViewer component
« Reply #6 on: June 24, 2018, 11:42:09 pm »
[...] Translated internal messages thrue PO files (use a modified TGVTranslate component from Gilles Vasseurs's french tutorial : https://gilles-vasseur.developpez.com/tutoriels/lazarus-traduction/
Why do you introduce a new translation system here? Lazarus has good built-in translation support, you only must activate the i18n option and define a language folder in the package settings, as well as declare the message strings as resource strings.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #7 on: June 25, 2018, 12:09:28 am »
Why do you introduce a new translation system here? Lazarus has good built-in translation support, you only must activate the i18n option and define a language folder in the package settings, as well as declare the message strings as resource strings.

Hi, it's not a new translation system. TGVTranslate it's just an helper. The i18n is activated but if i well understand it an application for example if i want have tanslation in french of lcl the po (lclstrconsts.fr.po in this case)  must be place in a subfolder of the application name "languages" after for loading just use
Code: Pascal  [Select]
  1. Translations.TranslateUnitResourceStrings('LCLStrConsts', LF);
where LF is the path where is po files. But perhaps i'm not understanding well on how to translate an application correctly. I like the possibility to change languages dynamically for testing. Translating french to english or vice-versa can occurs some problems in IHM due to the length of string. French sentence are often longer.

I'm open for all advices and suggestions

Notes : I've tested under Mac and  it doesn't work. I've a bug with folder settings. Don't say why. But i think i must add something in the bundle for make it work.


wp

  • Hero Member
  • *****
  • Posts: 5053
Re: TGIFViewer component
« Reply #8 on: June 25, 2018, 01:15:01 am »
My problem is that you seem to stuff too much unrelated material into the gifviewer package which is not absolutely needed or which could have more general use.

What do you want?

Provide a gifviewer? Then the units
- gvTranslate (similar stuff is in LCLTranslator)
- Typeshelpers (large overlap with type-helpers built into fpc now)
- and probably even uFastBitmap (because I am rather sure that you can paint the gif also with the routines of fcl-image)
are not needed.

Or do you want to provide a general-purpose package with translation utils, fast bitmap, additional type helpers and - of course - gif viewer? Then you should name the package differently and emphasize its multi-use character.

A few other comments:
  • I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.
  • Did you know that, unlike Delphi, fpc already has built-in gif support (unit fpreadgif in source folder packages/fp-image/src of the fpc installation)? I did not compare, but I am rather sure that there is a lot of overlap with your unit. Why write the same again when it's already there?
Please don't misunderstand these critical word - I really think your units are great work.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #9 on: June 25, 2018, 03:16:31 pm »
Hi, wp

My problem is that you seem to stuff too much unrelated material into the gifviewer package which is not absolutely needed or which could have more general use.

What do you want?

Provide a gifviewer? Then the units
- gvTranslate (similar stuff is in LCLTranslator)
LCLTranslator have not really the same purpose. LCLTranslator need more work to be use as is and quickly
I 've include this after the suggestions by Alextp to translate franch string to english for the general community

- Typeshelpers (large overlap with type-helpers built into fpc now)
I've included it because one of tester. Use an old version of lazarus but can be easly remove by replacing "ToString"  by "IntToStr" instead, or move to the gifview demo 's folder




Or do you want to provide a general-purpose package with translation utils, fast bitmap, additional type helpers and - of course - gif viewer? Then you should name the package differently and emphasize its multi-use character.

I just want to share my work. And i'm according to you gvTranslate, and TypesHelpers not really needed here

A few other comments:
  • I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.

I don't know that. Lazarus generate automatically One PO file for One Unit. Where i can set this option ? and how to manage it for translation ?

- and probably even uFastBitmap (because I am rather sure that you can paint the gif also with the routines of fcl-image)
are not needed.
  • Did you know that, unlike Delphi, fpc already has built-in gif support (unit fpreadgif in source folder packages/fp-image/src of the fpc installation)? I did not compare, but I am rather sure that there is a lot of overlap with your unit. Why write the same again when it's already there?

Yes i say that. But FPReadGIF not take in charge animation and it's not working properly just like with the BMP format for example where many file is not support correctly. Same problem with TGA, XPM, and PCX. PNG work well, but not complete. The only format that is about to handle correctly  is JPG.
My unit haven't a  lot of overlap. But many improved on how to read and support the GIF format. You can test, you'll see with FPC's many many GIF in the Imagetestsuite cannot be read correctly with FCL-Image.

I think the FPC and LAzarus graphics solution be must be rethinking. Just see a little part in my code why i can't manage transparency correclty with TBitmap (just under linux) and must use TLazIntfImage instead ? Lazarus have bigs problems with Bitmap management. Not FCL directly, but i'm think it was not a good choice to manage color as 64 bit (TFPColor) by default. FCL-Image is not enough optimized, error management is not good, many bug are present between and with LCL RawImage/TBitmap.

 I'm according to this issue (http://michellcomputing.co.uk/blog/2016/08/free-pascal-fast-bitmap-handling-part-1/). For TFastBitmap I could have done like here http://michellcomputing.co.uk/blog/2016/08/free-pascal-fast-bitmaps-part-2/ But not really needed.
I think graphics it's an important part of developpment. And a lot of work needs to be done at this level, for be use correctly. It's too far confusing and and has too much  hidden and unexpected bugs

It's my feeling and my opinion. but I think the teams should focus on all these small details and small persistent bugs from version to version, for giving more something more stable, especially to be able to cross compile properly without having to shield the code of {$ IFDEF} on basic things (I think of the TListView for example, or like here with the use of TLazIntfImage under Linux), rather than wanting to look like Delphi. Delphi is Delphi. FPC / Lazarus is FPCC / Lazarus that's it

All of this, of course, does not detract from the quality and work of the FPC and Lazarus developers of course for giving us pleasure to code

Please don't misunderstand these critical word - I really think your units are great work.

No problem, It's with discussions like this that we can move forward

Thanks and best regards

Jérôme
« Last Edit: June 25, 2018, 03:33:16 pm by BeanzMaster »

wp

  • Hero Member
  • *****
  • Posts: 5053
Re: TGIFViewer component
« Reply #10 on: June 25, 2018, 05:58:37 pm »
LCLTranslator have not really the same purpose. LCLTranslator need more work to be use as is and quickly
As I already wrote you don't need any translation unit at all for providing multi-language support for a package. Just
- declare all string constants as resourcestring
- activate i18n in the project options
- and define a folder for the po files created by the LCL.
You do exactly this in the gifviewer unit, and this is correct.

Things are different in an application, like your demo gifview. The application must know which version of the translated po files will have to be used, and it will have to switch between translations. For this purpose, translation support units are required. The key building blocks are contained in units such as "Translations" and "LCLtranslator", but I agree that there is a need for more ready-to-use routines.

I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.
I don't know that. Lazarus generate automatically One PO file for One Unit. Where i can set this option ? and how to manage it for translation ?
Lazarus creates a po template for each unit which contains at least one resourcestring declaration. In otder to have a single po file for the translators, you just should pack all resource strings into a single unit and "use" this in the package and in the application. The single resource string unit will correspond to a single po file. Look at Lazarus' lclstrconsts: it contains all the strings used by some unit of the LCL - this is for the LCL package. The application, Lazarus, has another translation unit, lazaruside, which collects all the strings used by the Lazarus application somewhere.

I just want to share my work.
Great!

FPReadGIF not take in charge animation
Agreed, and this is a good reason for your work.

I think the FPC and LAzarus graphics solution be must be rethinking. Just see a little part in my code why i can't manage transparency correclty with TBitmap (just under linux) and must use TLazIntfImage instead ? Lazarus have bigs problems with Bitmap management. Not FCL directly, but i'm think it was not a good choice to manage color as 64 bit (TFPColor) by default. FCL-Image is not enough optimized, error management is not good, many bug are present between and with LCL RawImage/TBitmap.
I don't agree. The FPC/Lazarus graphics units are more general than yours. Your gif viewer can only display gif images. The TImage of the LCL, on the other hand, can display any graphics format if it is registered. And FPC-Image can work with images even without the LCL. It took me quite some time until I understood this. In addition FCL-Image is rather difficult to use, and it is easy to make mistakes - therefore, it appears to be buggy. It is not, at least not more than any other software. Using FPC-Image it is possible to paint a transparent GIF for sure - transparent png is working too (all the icons of the IDE are transparent pngs). But of course, if you feel better with your fastbitmap - no problem.

You can test, you'll see with FPC's many many GIF in the Imagetestsuite cannot be read correctly with FCL-Image.
Which ImageTestSuite do you mean? I guess FPC's GIF reader does not support all features defined in the specification. The same with other formats. But usually the most important features are supported (in case of GIF, of course, except for animation).

I think the teams should focus on all these small details and small persistent bugs from version to version, for giving more something more stable, especially to be able to cross compile properly without having to shield the code of {$ IFDEF} on basic things (I think of the TListView for example, or like here with the use of TLazIntfImage under Linux), rather than wanting to look like Delphi.
I don't understand what you want to say here. As far as I know the graphics formats are not on the focus of the current development. But they are certainly maintained. So, if you find a bug please report it to bugtracker and somebody will take care of it. Also, if you find some pieces of your gif code which could be merged into the code of fpreadgif you should submit it to bugtracker.

- Typeshelpers (large overlap with type-helpers built into fpc now)
I've included it because one of tester. Use an old version of lazarus but can be easly remove by replacing "ToString"  by "IntToStr" instead, or move to the gifview demo 's folder
What would have been the problem to call "IntToStr" instead of "ToString" and adding an entire unit for it? In all the packages that I am maintaining I try to be as conservative as possible and avoid all new features in order to be able to allow old Lazarus and fpc versions.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #11 on: June 26, 2018, 01:05:33 am »

As I already wrote you don't need any translation unit at all for providing multi-language support for a package. Just
- declare all string constants as resourcestring
- activate i18n in the project options
- and define a folder for the po files created by the LCL.
You do exactly this in the gifviewer unit, and this is correct.

Things are different in an application, like your demo gifview. The application must know which version of the translated po files will have to be used, and it will have to switch between translations. For this purpose, translation support units are required. The key building blocks are contained in units such as "Translations" and "LCLtranslator", but I agree that there is a need for more ready-to-use routines.


Ok i think it's because GifViewer demo don't use the package. the component is creating at runtime. I'll check with newer demo

Lazarus creates a po template for each unit which contains at least one resourcestring declaration. In otder to have a single po file for the translators, you just should pack all resource strings into a single unit and "use" this in the package and in the application. The single resource string unit will correspond to a single po file. Look at Lazarus' lclstrconsts: it contains all the strings used by some unit of the LCL - this is for the LCL package. The application, Lazarus, has another translation unit, lazaruside, which collects all the strings used by the Lazarus application somewhere.

Ok it's what i've supposed as process.

I don't agree. The FPC/Lazarus graphics units are more general than yours. Your gif viewer can only display gif images. The TImage of the LCL, on the other hand, can display any graphics format if it is registered. And FPC-Image can work with images even without the LCL. It took me quite some time until I understood this. In addition FCL-Image is rather difficult to use, and it is easy to make mistakes - therefore, it appears to be buggy. It is not, at least not more than any other software. Using FPC-Image it is possible to paint a transparent GIF for sure - transparent png is working too (all the icons of the IDE are transparent pngs). But of course, if you feel better with your fastbitmap - no problem.

What I mean is that FCL-Image can be coded in a much simpler, more optimized and safer way. Actually in the background the FCL is not the big problems with graphics. The bugs essentially provides from the LCL

TFastBitmap is a very very simplified class of my project. And yes i prefer use it ;) you can see some oldschool demo i've wrote with it on my Youtube channel https://www.youtube.com/channel/UCyHRNjKUCYimY0f4c7We_rA/videos .

To talk about the FCL if you want help me to understand better FCL-Image. I opened a new topic: http://forum.lazarus.freepascal.org/index.php/topic,41674.0.html

Which ImageTestSuite do you mean? I guess FPC's GIF reader does not support all features defined in the specification. The same with other formats.
But usually the most important features are supported (in case of GIF, of course, except for animation).
This GIF-ImageTestSuite : https://github.com/jdelauney/GIF-ImageTestSuite.  and for BMP https://github.com/jdelauney/BMP-ImageTestSuite

Test the images in those 2 list you'll see that many things are not supported correctly.
 
I don't understand what you want to say here. As far as I know the graphics formats are not on the focus of the current development. But they are certainly maintained. So, if you find a bug please report it to bugtracker and somebody will take care of it. Also, if you find some pieces of your gif code which could be merged into the code of fpreadgif you should submit it to bugtracker.

I'd like to use Bugtracker, but i cannot access to it, i'm always rejected on login, i'm using my e-mail and the same password, ike say login page, but not working :(. I've a bunch of bugs and suggestions

What would have been the problem to call "IntToStr" instead of "ToString" and adding an entire unit for it? In all the packages that I am maintaining I try to be as conservative as possible and avoid all new features in order to be able to allow old Lazarus and fpc versions.
No problem with that, just happy sharing ;). I'll remove it in next update

Best regards

Alextp

  • Hero Member
  • *****
  • Posts: 700
    • UVviewsoft
Re: TGIFViewer component
« Reply #12 on: June 26, 2018, 08:12:31 am »
You can mail me to personal-messages your patches, and I ll post them to bugtracker.

BeanzMaster

  • Full Member
  • ***
  • Posts: 154
Re: TGIFViewer component
« Reply #13 on: June 27, 2018, 01:15:04 am »
Project Updated

  • Delete TypesHelpers Unit dependancy
  • Added AutoStretchMode property to TGifViewer
  • Added OnStretchModeChange Event to TGifViewer
  • Add Translation  to english for many comments
  • Create only one unit resourcestring for package
  • Updated GifView demo
  • Updated GifRes demo. New resource with FPC Logo
  • Move gvTranslate unit to GifView demo folder

You can mail me to personal-messages your patches, and I ll post them to bugtracker.

Thanks i think i'll try signup with another e-mail
I'll contact you thrue PM, for help me to send a good bug report ;)

wp

  • Hero Member
  • *****
  • Posts: 5053
Re: TGIFViewer component
« Reply #14 on: June 30, 2018, 01:20:32 pm »
Yes. Now I definitely like it.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus