[EMAIL PROTECTED] writes: > Often things that are only defined for _WIN32_WINNT > 0x0400 are not defined > in > the mingw headers, so we need to provide our own definitions anyway. I do > think > it makes it easier for future developers if we use the standard constant names > instead of inventing our own though, so > > #ifndef SPI_GETFONTSMOOTHINGTYPE > #define SPI_GETFONTSMOOTHINGTYPE 0x0200A > #endif
Makes sense. I just didn't know how close this was, legally speaking, to copying MS code into GPL'd code, and didn't want to risk it. But if you say it's fine, I'm happy. > Usually the system calls are pretty good about returning an error rather than > crashing if you try to use an unsupported feature, so a good runtime check is > to check the return value of the function being called. There are many > optional > addons to Windows 95 that add extra functionality (like full Unicode APIs), so > checking os_subtype is an inferior test IMHO - like testing system-type > instead > of featurep. > > I am worried about the performance impact of making two system calls to query > the configuration potentially every time a character is output (there is some > limited caching for ASCII, but Asian and East European languages that use > completely different scripts especially will suffer). I think performance in > this case is more important than the rare case where a user changes their > system settings during an Emacs session and starts seeing the display problems > (which are really nothing more than a minor annoyance), Unless you happen to actually use ClearType, in which case it's killer. > so I'd be happier moving the check for Cleartype into > w32_initialize() and just checking a file scope variable in > w32_native_per_char_metric() Is there some appropriate windows event (like "application just came to the foreground", however you spell that in Wind-ese) that we can use to check the state and set the global? That would be close to perfect. If not, I'll be happy to check once in w32_initialize. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
