Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!

Organizing tasks to work on, New Features Ideas, Building LCS & LCB Libraries & Widgets, Redecorating and Modifying the IDE, Hacking / Editing Tools, Compiling the Engine from Source, etc.
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!

Post by tperry2x »

Oh, okay - yes. That's a relief because I already knew about that (thanks for clarifying with pics), just reassuring to know that we are all talking about the same thing sometimes!

I'm building that into my new properties inspector, as I use it all the time already:
Screenshot at 2024-03-28 12-19-16.png
Screenshot at 2024-03-28 12-19-16.png (13.48 KiB) Viewed 2356 times
I just wanted to check I wasn't missing anything obvious.
What does the "Set:" refer to?

Coming back on topic - I'm wondering if it would be possible to build gif editing into my properties inspector. I don't want to run before I can walk though, but I'm thinking the simplest way would just be to have a button on my properties inspector, that when you select a gif image, it opens paul's gif editing stack. Would that work? My hope is we can combine all these bits together.
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!

Post by OpenXTalkPaul »

xAction wrote: Thu Mar 28, 2024 9:15 am Any time you have an array in memory, shoving it into a custom property is a good way to get a look at it without printing it the message box or a file. Great for seeing "Oh, that's all wrong!"
Yes, but do you see in your screenshot of the property inspector, where there's a "+" and a trash can svg icon?
That is where the Property Inspector is using the 'Tree view widget", which can be use in our own stacks like any other widget can, and this is another super-quick way to view an array variable's contents in a hierarchical view. It has 'array' mode, editing or a read-only viewing modes and some other options.
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Parsing GIF Format (NOT using Extension Builder ) SUCCESS!!!

Post by OpenXTalkPaul »

tperry2x wrote: Thu Mar 28, 2024 12:21 pm Oh, okay - yes. That's a relief because I already knew about that (thanks for clarifying with pics), just reassuring to know that we are all talking about the same thing sometimes!

I'm building that into my new properties inspector, as I use it all the time already:
Screenshot at 2024-03-28 12-19-16.png

I just wanted to check I wasn't missing anything obvious.
What does the "Set:" refer to?

Coming back on topic - I'm wondering if it would be possible to build gif editing into my properties inspector. I don't want to run before I can walk though, but I'm thinking the simplest way would just be to have a button on my properties inspector, that when you select a gif image, it opens paul's gif editing stack. Would that work? My hope is we can combine all these bits together.
That would be great!
I think it still needs a bunch of work, specially in the GUI cosmetics department. I imagine having a thumbnail images list or maybe a timeline view to represent animation frames. Some functions I planned to optimize for speed. For example I've already made a separate handler that only reads the GIF's Header data, and returns GIF's global Width and Height, without parsing though the rest of the GIF's Data so that it returns much much faster if you only need to get the image's size information. Other functionality could be similarly optimized for speed ( getGlobalColorPaletteFromGIF() already in the works ). I also want to be able to return color palettes as PBM-ASCII-Text or as Pixel ImageData for a color swatch or a for a whole color set (as seen in your new-version of Inspector), or as a textColor-Styled-text list (as seen in my 'Swatches' Palette). And finally I was going to also make this all be more of an extension / script-only stack library thing.

While testing this stuff I've seem some considerable lagging as soon as I try to play two or more, usually larger size, animated GIFs (I have some test animated GIF's that are like 1280x1600), when the frame delay times are timed too closely to each other. If I pause one and then resume often the lagging will go away, likely because the rendering timing changed, giving it enough time to render one frame of GIF one before it's time to render the GIF two's next frame. I'm guessing this is related to the fact that there is only a single thread used for all UI drawing stuff (there is another thread that's that scripts run in).
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests