gtk/gdk/win32/gdkvisual-win32.c

345 lines
8.4 KiB
C
Raw Normal View History

/* GDK - The GIMP Drawing Kit
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
* Copyright (C) 1998-2002 Tor Lillqvist
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
2012-02-27 13:01:10 +00:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
/*
* Modified by the GTK+ Team and others 1997-2000. See the AUTHORS
* file for a list of people on the GTK+ Team. See the ChangeLog
* files for a list of changes. These files are distributed with
* GTK+ at ftp://ftp.gtk.org/pub/gtk/.
*/
#include "config.h"
#include <stdlib.h>
#include "gdkvisual.h"
#include "gdkscreen.h" /* gdk_screen_get_default() */
#include "gdkprivate-win32.h"
#include "gdkvisualprivate.h"
static void gdk_visual_decompose_mask (gulong mask,
gint *shift,
gint *prec);
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
static GdkVisual *system_visual = NULL;
static gint available_depths[1];
static GdkVisualType available_types[1];
void
_gdk_visual_init (GdkScreen *screen)
{
struct
{
BITMAPINFOHEADER bi;
union
{
RGBQUAD colors[256];
DWORD fields[256];
} u;
} bmi;
HBITMAP hbm;
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
const gint rastercaps = GetDeviceCaps (_gdk_display_hdc, RASTERCAPS);
const int numcolors = GetDeviceCaps (_gdk_display_hdc, NUMCOLORS);
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
gint bitspixel = GetDeviceCaps (_gdk_display_hdc, BITSPIXEL);
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
gint map_entries = 0;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual = g_object_new (GDK_TYPE_VISUAL, NULL);
system_visual->screen = screen;
if (rastercaps & RC_PALETTE)
{
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
const int sizepalette = GetDeviceCaps (_gdk_display_hdc, SIZEPALETTE);
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
gchar *max_colors = getenv ("GDK_WIN32_MAX_COLORS");
system_visual->type = GDK_VISUAL_PSEUDO_COLOR;
g_assert (sizepalette == 256);
if (max_colors != NULL)
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
_gdk_max_colors = atoi (max_colors);
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
map_entries = _gdk_max_colors;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
if (map_entries >= 16 && map_entries < sizepalette)
{
if (map_entries < 32)
{
map_entries = 16;
system_visual->type = GDK_VISUAL_STATIC_COLOR;
bitspixel = 4;
}
else if (map_entries < 64)
{
map_entries = 32;
bitspixel = 5;
}
else if (map_entries < 128)
{
map_entries = 64;
bitspixel = 6;
}
else if (map_entries < 256)
{
map_entries = 128;
bitspixel = 7;
}
else
g_assert_not_reached ();
}
else
map_entries = sizepalette;
}
else if (bitspixel == 1 && numcolors == 16)
{
bitspixel = 4;
system_visual->type = GDK_VISUAL_STATIC_COLOR;
map_entries = 16;
}
else if (bitspixel == 1)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->type = GDK_VISUAL_STATIC_GRAY;
map_entries = 2;
}
else if (bitspixel == 4)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->type = GDK_VISUAL_STATIC_COLOR;
map_entries = 16;
}
else if (bitspixel == 8)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->type = GDK_VISUAL_STATIC_COLOR;
map_entries = 256;
}
else if (bitspixel == 16)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->type = GDK_VISUAL_TRUE_COLOR;
#if 1
/* This code by Mike Enright,
* see http://www.users.cts.com/sd/m/menright/display.html
*/
memset (&bmi, 0, sizeof (bmi));
bmi.bi.biSize = sizeof (bmi.bi);
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
hbm = CreateCompatibleBitmap (_gdk_display_hdc, 1, 1);
GetDIBits (_gdk_display_hdc, hbm, 0, 1, NULL,
(BITMAPINFO *) &bmi, DIB_RGB_COLORS);
gdk/win32/gdkprivate-win32.h Rename all global variables and functions to 2002-11-12 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/*.c: Rename all global variables and functions to start with underscore. Merge from stable: More work on the Win32 backend. The cause of some scrolling problems was that SetWindowPos() and ScrollWindowEx() don't blit those parts of the window they think are invalid. As we didn't keep Windows's update region in synch with GDK's, Windows thought those areas that in fact had been updated were invalid. Calling ValidateRgn() in _gdk_windowing_window_queue_antiexpose() seems to be an elegant and efficient solution, removing from Windows's update region those areas we are about to repaint proactively. In some cases garbage leftover values were used for the clip origin in GdkGCWin32. This showed up as odd blank areas around the pixmaps included in the Text Widget in gtk-demo. Having the clip region either as a GdkRegion or a HRGN in GdkGCWin32 was unnecessary, it's better to just use a HRGN. The translation and antiexpose queue handling in gdkgeometry-win32.c seems unnecessary (and not implementable in the same way as on X11 anyway, no serial numbers) on Windows, ifdeffed out. Don't (try to) do guffaw scrolling as there is no static window gravity on Windows. Guffaw scrolling would be unnecessary anyway, as there is the ScrollWindow() API. This improves the behaviour of the Text Widget demo in gtk-demo a lot. But I have no idea how the lack of static win gravity should be handled in other places where the X11 code uses it. Especially _gdk_window_move_resize_child(). There is still some problem in expose handling. By moving an obscuring window back and forth over testgtk's main window, for instance, every now and then you typically get narrow vertical or horizontal strips of pixels that haven't been properly redrawn after being exposed. A fencepost error somewhere? Otherwise, all of testgtk and gtk-demo except "big windows" now seem to work pretty well. Bug #79720 should be fixed now. * gdk/win32/gdkcolor-win32.c (gdk_win32_color_to_string, gdk_win32_print_paletteentries, gdk_win32_print_system_palette, gdk_win32_print_hpalette) * gdk/win32/gdkdrawable-win32.c (gdk_win32_drawable_description) * gdk/win32/gdkevents-win32.c (gdk_win32_message_name): Move all debugging helper functions to gdkmain-win32.c. * gdk/win32/gdkdrawable-win32.c (_gdk_win32_draw_tiles): Rewrite. Make static. Must take tile origin parameters, too. (gdk_win32_draw_rectangle): Pass the tile/stipple origin to _gdk_win32_draw_tiles(). Remove #if 0 code. (blit_inside_window): Don't call ScrollDC(), that didn't work at all like I thought. A simple call to BitBlt() is enough. * gdk/win32/gdkevents-win32.c (gdk_event_translate) Remove unused latin_locale_loaded variable. (_gdk_win32_get_next_tick): New function. Used to make sure timestamps of events are always increasing, both in events generated from the window procedure and in events gotten via PeekMessage(). Not sure whether this is actually useful, but it seemed as a good idea. (real_window_procedure): Don't use a local GdkEventPrivate variable. Don't attempt any compression of configure or expose events here, handled elsewhere. (erase_background): Accumulate window offsets when traversing up the parent chain for GDK_PARENT_RELATIVE_BG, in order to get correct alignment of background pixmaps. Don't fill with BLACK_BRUSH if GDK_NO_BG. (gdk_event_get_graphics_expose): A bit more verbose debugging output. (gdk_event_translate): Use _gdk_win32_get_next_tick(). In the WM_PAINT handler, don't check for empty update rect. When we get a WM_PAINT, the update region isn't empty. And if it for some strange reason is, that will be handled later anyway. Call GetUpdateRgn() before calling BeginPaint() and EndPaint() (which empty the update region). * gdk/win32/gdkdnd-win32.c * gdk/win32/gdkinput-win32.c: Use _gdk_win32_get_next_tick(). * gdk/win32/gdkfont-win32.c: Use %p to print HFONTs. (gdk_text_size): Remove, unused. * gdk/win32/gdkgc-win32.c: Set clip origins to zero when appropriate. (gdk_gc_copy): Increase refcount on colormap if present. (gdk_win32_hdc_get): Handle just hcliprgn. If we have a stipple, combine it with clip region after selecting into the DC. (_gdk_win32_bitmap_to_hrgn): Rename from _gdk_win32_bitmap_to_region. (_gdk_win3_gdkregion_to_hrgn): New function, code snippet extracted from gdk_win32_hdc_get(). * gdk/win32/gdkgeometry-win32.c: Ifdef out the translate_queue handling. (gdk_window_copy_area_scroll): Increase clipRect to avoid ScrollWindowEx() not scrolling pixels it thinks are invalid. Scroll also children with the ScrollWindowEx() call. No need to call gdk_window_move() on the children. (gdk_window_scroll): Don't do guffaw scrolling. (gdk_window_compute_position): Fix typo, used win32_y where x was intended. (gdk_window_premove, gdk_window_postmove, gdk_window_clip_changed): Add debugging output. (_gdk_windowing_window_queue_antiexpose): Just call ValidateRgn() on the region. (_gdk_window_process_expose): No use for the serial number parameter now. Instead of a rectangle, take a region parameter, as Windows gives us one in WM_PAINT. * gdk/win32/gdkmain-win32.c (_gdk_win32_lbstyle_to_string, _gdk_win32_pstype_to_string, _gdk_win32_psstyle_to_string, _gdk_win32_psendcap_to_string, _gdk_win32_psjoin_to_string, _gdk_win32_rect_to_string, _gdk_win32_gdkrectangle_to_string, _gdk_win32_gdkregion_to_string): New debugging functions. (static_printf): Helper function for the above. sprintfs into a static circular buffer, return value should be used "soon". * gdk/win32/gdkwindow-win32.c (gdk_propagate_shapes): Plug memory leak, free list after use. (gdk_window_gravity_works): Remove, we know that there is no such thing on Windows. (gdk_window_set_static_bit_gravity, gdk_window_set_static_win_gravity): Ditto, remove, they didn't do anything anyway. (_gdk_windowing_window_init, gdk_window_foreign_new): Call _gdk_window_init_position() like in the X11 backend. (gdk_window_reparent): Don't call the now nonexistent gdk_window_set_static_win_gravity(). No idea what should be done instead. (gdk_window_get_geometry): The returned x and y should be relative to parent. Used to be always zero.. (gdk_window_set_static_gravities): Return FALSE if trying to set static gravity. * gdk/win32/gdkprivate-win32.h: Drop the clip_region field from GdkGCWin32. Only use the HRGN hcliprgn. Declare new functions. * gdk/win32/*.c: Use new debugging functions. * gdk/win32/rc/gdk.rc.in: Update copyright year.
2002-11-12 22:17:48 +00:00
GetDIBits (_gdk_display_hdc, hbm, 0, 1, NULL,
(BITMAPINFO *) &bmi, DIB_RGB_COLORS);
DeleteObject (hbm);
if (bmi.bi.biCompression != BI_BITFIELDS)
{
/* Either BI_RGB or BI_RLE_something
* .... or perhaps (!!) something else.
* Theoretically biCompression might be
* mmioFourCC('c','v','i','d') but I doubt it.
*/
if (bmi.bi.biCompression == BI_RGB)
{
/* It's 555 */
bitspixel = 15;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->red_mask = 0x00007C00;
system_visual->green_mask = 0x000003E0;
system_visual->blue_mask = 0x0000001F;
}
else
{
g_assert_not_reached ();
}
}
else
{
DWORD allmasks =
bmi.u.fields[0] | bmi.u.fields[1] | bmi.u.fields[2];
int k = 0;
while (allmasks)
{
if (allmasks&1)
k++;
allmasks/=2;
}
bitspixel = k;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->red_mask = bmi.u.fields[0];
system_visual->green_mask = bmi.u.fields[1];
system_visual->blue_mask = bmi.u.fields[2];
}
#else
/* Old, incorrect (but still working) code. */
#if 0
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->red_mask = 0x0000F800;
system_visual->green_mask = 0x000007E0;
system_visual->blue_mask = 0x0000001F;
#else
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->red_mask = 0x00007C00;
system_visual->green_mask = 0x000003E0;
system_visual->blue_mask = 0x0000001F;
#endif
#endif
}
else if (bitspixel == 24 || bitspixel == 32)
{
bitspixel = 24;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->type = GDK_VISUAL_TRUE_COLOR;
system_visual->red_mask = 0x00FF0000;
system_visual->green_mask = 0x0000FF00;
system_visual->blue_mask = 0x000000FF;
}
else
Make gdkx.h the only installed header from gdk/x11. All structures in Fri Sep 7 11:51:44 2001 Owen Taylor <otaylor@redhat.com> Make gdkx.h the only installed header from gdk/x11. All structures in gdk/x11 are opaque. * gdk/x11/Makefile.am gdk/x11/gdkx.h gdk/x11/gdkprivate-x11.h: Don't install gdk{drawable,pixmap,window}-x11.h. * gdk/x11/{gdkcolormap-x11.c, gdkfont-x11.c, gdkx.h, gdkvisual-x11.c: Move GdkColormapPrivateX11, GdkFontPrivateX GdkImagePrivateX11, GdkVisualClass into C files. * gdk/gdkpixmap-x11.[ch]: Make gdk_pixmap_impl_get_type() static. * gdk/x11/{gdkcolor-x11.c, gdkcursor-x11.c, gdkdrawable-x11.c, gdkfont-x11.c, gdkgc-x11.c, gdkx.h, gdkimage-x11,gdkvisual-x11.c} Add public functions to replace previously exported direct structure access. gdk_x11_colormap_get_{xdisplay,xcolormap} gdk_x11_cursor_get_{xdisplay,xcursor}, gdk_x11_drawable_get_{xdisplay,xcursor,gdk_x11_visual_get_xvisual, gdk_x11_font_get_{xdisplay,xfont}, gdk_x11_image_get_{xdisplay,ximage}, gdk_x11_gc_get_{xdisplay,ximage} * gdk/gdkprivate.h gdk/gdkinternals.h: Move GdkColorInfo, GdkEventFilter, GdkClientFilter, GdkFontPrivate to gdkinternals. Fix a number of variables and functions that were exported "accidentally" from GDK. * gdk/**.[ch]: gdk => _gdk for gdk_visual_init, gdk_events_init, gdk_input_init, gdk_dnd_init, gdk_image_exit, gdk_input_exit, gdk_windowing_exit, gdk_event_func, gdk_event_data, gdk_event_notify, gdk_queued_events, gdk_queued_tail, gdk_event_new, gdk_events_queue, gdk_events_unqueue, gdk_event_queue_find_first, gdk_event_queue_remove_link, gdk_event_queue_append, gdk_event_button_generate, gdk_debug_flags, gdk_default_filters, gdk_parent_root. * gdk/x11/{gdkevents-x11.c, gdkglobals-x11.c, gdkimage-x11.c, gdkmain-x11.c, gdkprivate-x11.h, gdk/x11/gdkwindow-x11.c}: gdk => _gdk for gdk_event_mask_table, gkd_nevent_masks, gdk_wm_window_protocols, gdk_leader_window, gdk_xgrab_window, gdk_use_xshm, gdk_input_ignore_core. * gdk/x11/xsettings-common.h (xsettings_list_insert): Add #defines to namespace functions into the private _gdk_ namespace. * gdk/gdkwindow.[ch] gdk/x11/gdkx.h: Add gdk_get_default_root_window () to replace gdk_parent_root exported variable. Adjust and deprecate GDK_ROOT_PARENT(). * demos/{testpixbuf-drawable.c,testpixbuf-save.c}: Fix GDK_ROOT_PARENT usage, remove includes of port-specific headers. * gdk/{win32,x11,fb}/gdkinput*.[ch]: s/gdk/_gdk/ for _gdk_input_gxid_host, _gdk_input_gxid_port, _gdk_input_ignore_core, gdk_input_devices, _gdk_input_windows, gdk_init_input_core. * gdk/x11/{gdkevents-x11.,c gdkglobals-x11.c, gdkmain-x11.c} docs/Changes-2.0.txt: Remove gdk_wm_protocols, gdk_wm_delete_window functions, gdk_wm_take_focus, use gdk_atom_intern() instead. * gdk/linux-fb/{gdkselection-fb.c, gdkmain-fb.c, gdkprivatefb.h} gdk/win32/{gdkselection-win32.c, gdkmgdkwin32.h, gdkprivate-win32.h} gdk/x11/{gdkselection-x11.c gdkx.h, gtkprivate-x11.h} gtk/gtkselection.c Unexport gdk_selection_property, just use gdk_atom_intern ("GDK_SELECTION"). * gdk/x11/{gdkprivate-x11.h,gdkdrawable-x11h,gdkgc-x11.c,gdkx.h}: Unexport gdk_drawable_impl_x11_get_type, gdk_gc_x11_get_type, GDK_GC_X11 cast macros, GdkGCX11 structures, GdkCursorPrivate, GdkVisualprivate, gdk_x11_gc_flush. Make a number of public exports of variables into functions to increase encapsulation. * gdk/gdkinternals.h gdk/gdkinput.h gdk/gdkevents.h gdk/linux-fb/gdkmouse-fb.c: gdk_core_pointer => _gdk_core_pointer, move to gdkinternals.h. Add gdk_device_get_core_pointer (). * gdk/gdkprivate.h gdk/gdkpango.c gdk/gdkinternals.h docs/Changes-2.0.txt: Unexport gdk_parent_root, gdk_error_code, gdk_error_warnings. * gdk/x11/{gdkcolormap-x11.c, gdkmain-x11.c, gdkx.h} docs/Changes-2.0.txt: s/gdk_screen/_gdk_screen/, add gdk_x11_get_default_screen() s/gdk_root_window/_gdk_root_window/, add gdk_x11_get_default_root_xwindow() Add gdk_x11_get_default_xdisplay(). * gdk/gdk.h gdk/gdk.c linux-fb/gdkfb.h linux-fb/gdkglobals-fb.c win32/gdkwin32.h x11/gdkglobals-x11.c gdk/x11/gdkmain-x11.c gdk/x11/gdkx.h: gdk/gdk.def: Add gdk_get/set_program_class, Don't export gdk_progclass, move --class command line option and handling to common portion of GDK. Miscellaneous fixes: * gdk/x11/gdkwindow-x11.c (gdk_window_set_icon_list): Fix g_return_val_if_fail that should have been g_return_if_fail. * gdk/gdkinternals.h gdk/gdkprivate.h: Move gdk_synthesize_window_state() to the semi-public gdkprivate.h. * gtk/gtkdnd.c (_gtk_drag_source_handle_event): Remove uneeded X11 dependency. * gdk/linux-fb/gdkmain-fb.c gdk/win32/gdkmain-win32.c gdk/TODO: Remove unused gdk_key_repeat_disable/restore. * linux-fb/gdkglobals-fb.c win32/gdkglobals-win32.c x11/gdkglobals-x11.c x11/gdkprivate-x11.h gdk/gdk.def: Remove unused gdk_null_window_warnings variable. * gdk/Makefile.am (DIST_SUBDIRS) nanox/*: cvs remove nanox; it can be retrieved from the repository; it is too far from functional to be worth having people check out; it would be easier to start from scratch, I suspect. * gdk/x11/gdkpixmap-x11.c: Fix lvalue usage of GDK_PIXMAP_XID(). * gdk/x11/gdkkeys-x11.c gdk/gdkrgb.c gdk/gdkwindow.c gdk/x11/gdkpango-x11.c gdk/x11/gdkselection-x11.c: Fix some accidentally global variables and unused global variables. * gdk/x11/gdkkeys-x11.c gdk/gdkrgb.c gdk/gdkwindow.c gdk/x11/gdkpango-x11.c gdk/x11/gdkselection-x11.c: Fix some accidentally global variables and unused global variables. Add some space for future expansion to multihead. * gdk/gdkdrawable.h: Add four reserved function pointers for future expansion of GdkDrawableClass. * gtk/gtkwindow.h gtk/gtkinvisible.h: Add reserved pointer where we can put a GdkScreen * later.
2001-09-07 21:50:20 +00:00
g_error ("_gdk_visual_init: unsupported BITSPIXEL: %d\n", bitspixel);
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->depth = bitspixel;
system_visual->byte_order = GDK_LSB_FIRST;
system_visual->bits_per_rgb = 42; /* Not used? */
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
if ((system_visual->type == GDK_VISUAL_TRUE_COLOR) ||
(system_visual->type == GDK_VISUAL_DIRECT_COLOR))
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
gdk_visual_decompose_mask (system_visual->red_mask,
&system_visual->red_shift,
&system_visual->red_prec);
gdk_visual_decompose_mask (system_visual->green_mask,
&system_visual->green_shift,
&system_visual->green_prec);
gdk_visual_decompose_mask (system_visual->blue_mask,
&system_visual->blue_shift,
&system_visual->blue_prec);
map_entries = 1 << (MAX (system_visual->red_prec,
MAX (system_visual->green_prec,
system_visual->blue_prec)));
}
else
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->red_mask = 0;
system_visual->red_shift = 0;
system_visual->red_prec = 0;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->green_mask = 0;
system_visual->green_shift = 0;
system_visual->green_prec = 0;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->blue_mask = 0;
system_visual->blue_shift = 0;
system_visual->blue_prec = 0;
}
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
system_visual->colormap_size = map_entries;
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
available_depths[0] = system_visual->depth;
available_types[0] = system_visual->type;
}
gint
_gdk_win32_screen_visual_get_best_depth (GdkScreen *screen)
{
return available_depths[0];
}
GdkVisualType
_gdk_win32_screen_visual_get_best_type (GdkScreen *screen)
{
return available_types[0];
}
GdkVisual*
_gdk_win32_screen_get_system_visual (GdkScreen *screen)
{
return system_visual;
}
GdkVisual*
_gdk_win32_screen_visual_get_best (GdkScreen *screen)
{
return ((GdkVisual*) system_visual);
}
GdkVisual*
_gdk_win32_screen_visual_get_best_with_depth (GdkScreen *screen, gint depth)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
if (depth == system_visual->depth)
return (GdkVisual*) system_visual;
else
return NULL;
}
GdkVisual*
_gdk_win32_screen_visual_get_best_with_type (GdkScreen *screen, GdkVisualType visual_type)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
if (visual_type == system_visual->type)
return system_visual;
else
return NULL;
}
GdkVisual*
_gdk_win32_screen_visual_get_best_with_both (GdkScreen *screen,
gint depth,
GdkVisualType visual_type)
{
Massive changes. Too many to list here, but I'll try a summary: 2002-02-17 Tor Lillqvist <tml@iki.fi> * gdk/win32/*.c: Massive changes. Too many to list here, but I'll try a summary: 1) Unify GdkPixmap and GdkImage implementation: For each GdkPixmap, allocate a GdkImage, and vice versa. GdkPixmapImplWin32Data has a pointer to the GdkImage. GdkImage::windowing_data is a pointer to the GdkPixmap. This simplifies many pixmap and image related functions a lot, and reduces duplicated code snippets. For instance, there is only one place in gdk/win32 where CreateDIBSection() is called, in the function _gdk_win32_new_pixmap(). Converting a bitmap (GdkPixmap) to a Windows region is almost trivial, with the bitmap bits being readily accessible in the associated GdkImage. All blitting between GdkPixmaps, GdkWindows and GdkImages goes through handled the _gdk_win32_blit() function, which calls different functions to handle the cases of blitting from pixmaps, inside windows (scrolling), or from windows, which all require somewhat different handling. 2) Support 256-color mode. This has long been very broken, now it works more or less OK. Keep the logical palette for each colormap as small as possible while allocating and freeing colors. Select and realize the logical palette associated with a GdkColormap into a DC before drawing or blitting. When the display is in 256-color mode, make it possible for the user to override the size of the palette(s) used with either the GDK_WIN32_MAX_COLORS environment variable, or a -max-colors command line option. It is possible to reduce the palette size all the way down to using just the 16 static colors (which causes the system visual to be of type GDK_VISUAL_STATIC_COLOR. This could possibly be useful if one desperately wants to avoid color flashing. (Note that in order for this to work properly, an as of yet not commited fix to gdkrgb.c is needed.) Handle the palette messages. On WM_PALETTECHANGED, call UpdateColors() for the given window hierarchy. Do this only if a window in some other top-level window hierarchy caused the palette change (realized a palette). Do this max five times in a row (an arbitrarily chosen limit), though, otherwise redraw by generating expose events. On WM_QUERYNEWPALETTE, cause a redraw of the whole window hierarchy by generating GDK_EXPOSE events. 3) Code cleanup in general. For instance, remove the "emulated" X11 structs ColormapStruct, Visual and XStandardColormap. Use the new GDK_DEBUG_* flags for debugging output in the relevant source files. Remove the unused colormap hash table in gdkcolor-win32.c 4) Plug some resource leaks. 2002-02-14 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkdnd-win32.c (gdk_dropfiles_filter): Use g_filename_to_uri() to actually create legal URIs in the text/uri-list data.
2002-02-17 00:25:05 +00:00
if ((depth == system_visual->depth) && (visual_type == system_visual->type))
return system_visual;
else
return NULL;
}
void
_gdk_win32_screen_query_depths (GdkScreen *screen,
gint **depths,
gint *count)
{
*count = 1;
*depths = available_depths;
}
void
_gdk_win32_screen_query_visual_types (GdkScreen *screen,
GdkVisualType **visual_types,
gint *count)
{
*count = 1;
*visual_types = available_types;
}
GList*
_gdk_win32_screen_list_visuals (GdkScreen *screen)
{
return g_list_append (NULL, (gpointer) system_visual);
}
static void
gdk_visual_decompose_mask (gulong mask,
gint *shift,
gint *prec)
{
*shift = 0;
*prec = 0;
while (!(mask & 0x1))
{
(*shift)++;
mask >>= 1;
}
while (mask & 0x1)
{
(*prec)++;
mask >>= 1;
}
}