Re: [TCLCORE] TIP 714: image driver photo formats

[Harald O. <har...@el...>]

Dear group,

sorry, I was wrong in one point of my message:

Am 09.04.2025 um 14:41 schrieb Harald Oehlmann:
> Dear Emiliano,
> 
> thanks for the message. Please allow me to reply inline.
> 
> Am 09.04.2025 um 02:25 schrieb Emiliano:
>> On Thu, 3 Apr 2025 10:41:53 +0200
>> Harald Oehlmann <har...@el...> wrote:
>>
>> IMO this is the opportunity to fix some issues wrt the image type 
>> registration
>> and its implementation.
> 
> Yes, great !
> 
>> In this case, the list is walked from the start adding the .name 
>> member of
>> the Tk_ImageInfo structure until the .nextPtr member is null. Same with
>> [image create $type]: the list is walked until $type matches the .name
>> member. The result is
>>
>> * [image types] always grows, and can get duplicates.
>> * the first (last added) of the duplicated type names shadows the 
>> later ones.
>>
>> This last fact is easy to test
>>
>>    % image create bitmap
>>    Violación de segmento (`core' generado)
>>
>> I have a fix for the duplicated names issue. Since TIP#714 implements a
>> hash table to hold the registered Tk_ImageInfoProc, I've changed the
>> linked list for a(n internal) wrapper struct to hold both Tk_ImageType 
>> and
>> Tk_ImageInfoProc, and using the hash table to hold these wrappers.
>> If there are no questions, I'm going to commit it in a couple days in the
>> tip-714-alt branch, so it can be reviewed.
> 
> Thank you for working on this. IMHO, this is a bug of the current 
> implementation and is not TIP 714 related.
> Could you open a bug ticket and provide the fix there?
> I prefer to have the discussion archived somewhere and a ticket is a 
> great place.
> 
> I think, even with the current data structure, it would be possible to 
> avoid double registrations, but the list must be scanned for the name 
> entry. Currently, Tk_CreateImageType can not return an error on double 
> registration.
> 
>> Another issue identified has to do with the fact that image type managers
>> are implemented at thread level; newly registered image types are visible
>> in all interpreters in the same thread. Also, there's no provision to 
>> remove
>> an image type. These gotchas makes image type managers not well suited
>> to be implemented as extensions, since extensions are limited to
>> the interpreter which loads them (is this assumption true?). 
>> Interactively:
>>
>>    # loading in a child interp, visible from parent interp
>>    $ wish9.1
>>    % interp create i
>>    i
>>    % i eval {load ./libbadimage.so}
>>    % i eval {image types}
>>    bitmap photo bitmap
>>    % image types
>>    bitmap photo bitmap
>>
>> But this is subject for another TIP. Also, the photo image type format 
>> list
>> is also thread data; [package require ::img::jpeg] makes Tk photo image
>> supports jpeg in all the interpreters in the thread in which Tk is 
>> loaded.
> 
> I think, the thread issue is also a bug and may be handled in a ticket.
> Tk is slowly getting thread safe and this is another step in this 
> direction.

This is wrong. Making the Tk_CreateImageType only register for the 
current thread is a breaking change.
One may argue that there is nothing in the documentation about threads.
Yes, this was created in times where Tk was not jet thread aware.

Nevertheless, I get the impression that we need a successor for 
Tk_CreateImageType with the following features:

- only for current thread
- may return an error (already registered)
- maybe should make a copy of the passed data
- should have a version in the passed data structure for later extension
- may pass a thread local storage (don't know anything on this, but I 
see, that the image function may need this)
- contains an unregister call (which may fail).

So many questions...

Thanks for all,
Harald

---

I feel currently totally desesperate that we may handle the current 
issues. There are 5 Wizard points by Christian we should handle (3 in 
the recent mail + tksvg + tdbc::sqlite3).
And the "low hanging fruit" "image photo formats" is evolving to a mega 
project. As the final image goal is to load into tcl without tk, it 
feels even more impossible to reach...