[Xvid-devel] Patch for XVID MPEG-4 DirectShow/MediaFoundation filter

Michael Militzer michael at xvid.org
Tue Jun 14 20:54:51 CEST 2011


Hi Jerker,

I don't disagree with you that Unicode should be faster than ANSI for
Windows NT onwards. But the difference in speed will be completely
unnoticeable for Xvid, so this shouldn't be much of a consideration
here.

As to Unix users: I can't tell off-hand but I think any newer version
of Mingw should handle the _T() macros.

So could you modify your patch so that the code can be compiled with
both MBCS and Unicode char set?

Thanks,
Michael


Quoting Jerker Bäck <jerker.back at gmail.com>:

> Hi Matias,
>
>> Still, making the xvidcore both utf-16 utf-8 and ansi compatible is a good
>> thing.
> Yes couldn't agree more, this was my intention and the real benefit with
> this patch. And - I've got no real problem with the tchar.h _T() macro
> solution - works for me. AFAIK works for mingw also.
>
> More reflections:
> People with no Windows development experience usually misunderstands the
> UNICODE macro issue and think it's about international character translation
> and locale settings. They usually sigh and starts to talk about UTF8 as an
> alternative to UTF16 and mean this is superior in performance. Well, it's
> not about that. Instead the UNICODE macro is (was) an OS specific technical
> solution to allow transparent code shift from ANSI-based 16-bit Windows to
> Unicode (UTF16) based 32-bit Windows NT. Binary compiles without the UNICODE
> define uses the ANSI (A) compatibility layer Win32 functions and would work
> also on 16-bit Windows machines. On NT machines almost all the A functions
> translates into their W counterpart internally via an UTF16 character
> conversion (e.g. OutputDebugString() is an exception). The W (wide) version
> Win32 functions are also usually more powerful with larger buffers etc. So,
> it's usually true to say that the W version functions are faster and more
> efficient. In modern Win32 code the UNICODE define is standard.
>
> ANSI is nearly identical with ISO-8859-1, UTF8 is not used at all. In fact,
> I think dealing with UTF8 strings would be the least efficient in Windows
> (and not convenient as in BSD and Linux).
>
> Regards
> Jerker
>
> _______________________________________________
> Xvid-devel mailing list
> Xvid-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>





More information about the Xvid-devel mailing list