windowscodecs questions.

Max TenEyck Woodbury max at
Wed Oct 24 15:40:18 CDT 2012

On 10/24/2012 02:18 PM, Vincent Povirk wrote:
>>  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.
> That code is unused for reading and writing PNG images right now,
> sorry for the confusion. Libpng has its own code for reading and
> writing PNG chunks, and that is what is being used. Our chunk code is
> used for PNG metadata handlers (which will have to work independently
> from libpng so we can have a proper, pluggable system for metadata),
> but the architecture isn't there yet to use those handlers when
> reading a PNG image.
>>  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.
> None of that code should be used yet in a file with more than one
> block, so I don't know how this could be causing problems. My plan was
> that it would be up to the caller to seek to the next block based on
> the returned data size.
Hmm. With the version that reads the CRC, I get more error messages
and failures doing a 'make test' than the version without the addition.

>> 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.
> Please keep in mind that Guild Wars 2 is probably not using WIC
> directly. You should find out which library it's actually using
> (probably d3dx9, but could also be gdiplus or oleaut32's IPicture
> interface) and take that into account. We can modify users of WIC to
> use it in efficient ways, and/or optimize WIC for the way we are using
> it. (MSDN recommends reading the entire image once either in one
> CopyPixels call or in rows from top to bottom, and optimizing for that
> case. We don't do that yet because we needed the general case first.)
d3dx9.  From comments from the developers, they were having trouble
with slow access to their data file.  It's a huge thing, 30+GB.  (Yes,
that is a G, not an M).  I'd tried a patch on GetCount (which completely
misunderstood) and it went on to do something 'ReaderByIndex'.  It put
more images on the screen much faster for some reason.  I have very very
little information on the game's internal structure other than what
wine logs.

>> 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.
> I don't think a base class would've make anything easier.
>>  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'.
> We still couldn't do that because every interface vtable pointer would
> be at a different offset within the struct. We couldn't share them
> between encoders because different encoders have different data that
> they need to free. Anyway, it's not likely to have a measurable impact
> on performance.
OK. I was thinking every object based on IUnknown would start with a
VTable pointer, a critical section lock and a reference count.  I did
not expect to see any performance improvement, just the absence of
innumerable 'AddRef' and 'Release' variants.  In fact I sort of expected
both of them to go away as virtual functions with a virtual destructor
in their place.

> Could you share some results of your profiling? What is it that led
> you to believe the PNG code is a bottleneck?
Not allowed to profile as such.  It was just the difference in speed
when the game thought it had 'PNGGetCount'

More information about the wine-devel mailing list