Background: I am trying to improve the performance/reliability of GuildWars2 under wine. In particular, PNG handling seems very slow, so I am looking at windowscodecs and I seem to be misunderstanding some things. I have read the PNG spec.
First: The CRC check. The spec says that a 'chunk' contains a four byte size of data field, a four byte 'chunk identifier', the data and a CRC32 of the data.
I found some code that reads a generic chunk. I see where the size and type are read, where a correctly sized record is allocated and where the data is read into the record.
There is a 'FIXME' that asks about checking the CRC, but no code to actually read or check the CRC.
I added code to read and check the CRC to my working copy of the git tree. That threw off the block synchronization, so I think there is code someplace else that either checks or skips the CRC, but I have not found it after a few hours searching for it. An indication on where to look and other advice would be very helpful at this time.
Second: At least two of the methods GuildWars2 wants to use are stubbed. To implement those methods, the frame section of the WIC object should contain an array (or something with similar properties) of pointers to chunks. From what I have read about WIC, other formats could use a similar array. Some could even use an array of pointers to frames. Before I go messing with that level of change, I think I should listen to other peoples opinions of the subject.
Third: On a very broad level, the whole OLE implementation seems to be very messed up. In particular, the usual practice for doing inheritance in C does not seem to be being used. That practice is to have the elements common to the base and extending object be placed at the beginning of the implementing data structures. While the member names need not be the same in all instances, the function, type and order of the common elements must be the same for economical implementation.
This has been done for the basic object; all start with a pointer to the 'vtable'. What I think should follow is the critical section lock structure and, for 'IUnknown', the reference count. What I see is that these common elements are placed more or less at random in each extended object.
Is there any reason, other than inertia, that at least these two fields should not be moved to the beginning of implementing objects. This can be done one object at a time and would allow the changed objects to use a common implementation of 'AddRef' at least, and another common routine or macro that handles the critical part of 'Release'.