walkero
/
agg
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity
agg/include/platform/agg_platform_support.h

687 lines
30 KiB
C
Raw Normal View History

Initial commit with agg r138 svn files
2021-12-27 20:14:31 +01:00
//----------------------------------------------------------------------------
// Anti-Grain Geometry - Version 2.4
// Copyright (C) 2002-2005 Maxim Shemanarev (http://www.antigrain.com)
//
// Permission to copy, use, modify, sell and distribute this software
// is granted provided this copyright notice appears in all copies.
// This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
//
//----------------------------------------------------------------------------
// Contact: mcseem@antigrain.com
// mcseemagg@yahoo.com
// http://www.antigrain.com
//----------------------------------------------------------------------------
//
// class platform_support
//
// It's not a part of the AGG library, it's just a helper class to create
// interactive demo examples. Since the examples should not be too complex
// this class is provided to support some very basic interactive graphical
// functionality, such as putting the rendered image to the window, simple
// keyboard and mouse input, window resizing, setting the window title,
// and catching the "idle" events.
//
// The idea is to have a single header file that does not depend on any
// platform (I hate these endless #ifdef/#elif/#elif.../#endif) and a number
// of different implementations depending on the concrete platform.
// The most popular platforms are:
//
// Windows-32 API
// X-Window API
// SDL library (see http://www.libsdl.org/)
// MacOS C/C++ API
//
// This file does not include any system dependent .h files such as
// windows.h or X11.h, so, your demo applications do not depend on the
// platform. The only file that can #include system dependend headers
// is the implementation file agg_platform_support.cpp. Different
// implementations are placed in different directories, such as
// ~/agg/src/platform/win32
// ~/agg/src/platform/sdl
// ~/agg/src/platform/X11
// and so on.
//
// All the system dependent stuff sits in the platform_specific
// class which is forward-declared here but not defined.
// The platform_support class has just a pointer to it and it's
// the responsibility of the implementation to create/delete it.
// This class being defined in the implementation file can have
// any platform dependent stuff such as HWND, X11 Window and so on.
//
//----------------------------------------------------------------------------
#ifndef AGG_PLATFORM_SUPPORT_INCLUDED
#define AGG_PLATFORM_SUPPORT_INCLUDED
#include "agg_basics.h"
#include "agg_rendering_buffer.h"
#include "agg_trans_viewport.h"
#include "ctrl/agg_ctrl.h"
namespace agg
{
//----------------------------------------------------------window_flag_e
// These are flags used in method init(). Not all of them are
// applicable on different platforms, for example the win32_api
// cannot use a hardware buffer (window_hw_buffer).
// The implementation should simply ignore unsupported flags.
enum window_flag_e
{
window_resize = 1,
window_hw_buffer = 2,
window_keep_aspect_ratio = 4,
window_process_all_keys = 8
};
//-----------------------------------------------------------pix_format_e
// Possible formats of the rendering buffer. Initially I thought that it's
// reasonable to create the buffer and the rendering functions in
// accordance with the native pixel format of the system because it
// would have no overhead for pixel format conersion.
// But eventually I came to a conclusion that having a possibility to
// convert pixel formats on demand is a good idea. First, it was X11 where
// there lots of different formats and visuals and it would be great to
// render everything in, say, RGB-24 and display it automatically without
// any additional efforts. The second reason is to have a possibility to
// debug renderers for different pixel formats and colorspaces having only
// one computer and one system.
//
// This stuff is not included into the basic AGG functionality because the
// number of supported pixel formats (and/or colorspaces) can be great and
// if one needs to add new format it would be good only to add new
// rendering files without having to modify any existing ones (a general
// principle of incapsulation and isolation).
//
// Using a particular pixel format doesn't obligatory mean the necessity
// of software conversion. For example, win32 API can natively display
// gray8, 15-bit RGB, 24-bit BGR, and 32-bit BGRA formats.
// This list can be (and will be!) extended in future.
enum pix_format_e
{
pix_format_undefined = 0, // By default. No conversions are applied
pix_format_bw, // 1 bit per color B/W
pix_format_gray8, // Simple 256 level grayscale
pix_format_sgray8, // Simple 256 level grayscale (sRGB)
pix_format_gray16, // Simple 65535 level grayscale
pix_format_gray32, // Grayscale, one 32-bit float per pixel
pix_format_rgb555, // 15 bit rgb. Depends on the byte ordering!
pix_format_rgb565, // 16 bit rgb. Depends on the byte ordering!
pix_format_rgbAAA, // 30 bit rgb. Depends on the byte ordering!
pix_format_rgbBBA, // 32 bit rgb. Depends on the byte ordering!
pix_format_bgrAAA, // 30 bit bgr. Depends on the byte ordering!
pix_format_bgrABB, // 32 bit bgr. Depends on the byte ordering!
pix_format_rgb24, // R-G-B, one byte per color component
pix_format_srgb24, // R-G-B, one byte per color component (sRGB)
pix_format_bgr24, // B-G-R, one byte per color component
pix_format_sbgr24, // B-G-R, native win32 BMP format (sRGB)
pix_format_rgba32, // R-G-B-A, one byte per color component
pix_format_srgba32, // R-G-B-A, one byte per color component (sRGB)
pix_format_argb32, // A-R-G-B, native MAC format
pix_format_sargb32, // A-R-G-B, native MAC format (sRGB)
pix_format_abgr32, // A-B-G-R, one byte per color component
pix_format_sabgr32, // A-B-G-R, one byte per color component (sRGB)
pix_format_bgra32, // B-G-R-A, native win32 BMP format
pix_format_sbgra32, // B-G-R-A, native win32 BMP format (sRGB)
pix_format_rgb48, // R-G-B, 16 bits per color component
pix_format_bgr48, // B-G-R, native win32 BMP format.
pix_format_rgb96, // R-G-B, one 32-bit float per color component
pix_format_bgr96, // B-G-R, one 32-bit float per color component
pix_format_rgba64, // R-G-B-A, 16 bits byte per color component
pix_format_argb64, // A-R-G-B, native MAC format
pix_format_abgr64, // A-B-G-R, one byte per color component
pix_format_bgra64, // B-G-R-A, native win32 BMP format
pix_format_rgba128, // R-G-B-A, one 32-bit float per color component
pix_format_argb128, // A-R-G-B, one 32-bit float per color component
pix_format_abgr128, // A-B-G-R, one 32-bit float per color component
pix_format_bgra128, // B-G-R-A, one 32-bit float per color component
end_of_pix_formats
};
//-------------------------------------------------------------input_flag_e
// Mouse and keyboard flags. They can be different on different platforms
// and the ways they are obtained are also different. But in any case
// the system dependent flags should be mapped into these ones. The meaning
// of that is as follows. For example, if kbd_ctrl is set it means that the
// ctrl key is pressed and being held at the moment. They are also used in
// the overridden methods such as on_mouse_move(), on_mouse_button_down(),
// on_mouse_button_dbl_click(), on_mouse_button_up(), on_key().
// In the method on_mouse_button_up() the mouse flags have different
// meaning. They mean that the respective button is being released, but
// the meaning of the keyboard flags remains the same.
// There's absolut minimal set of flags is used because they'll be most
// probably supported on different platforms. Even the mouse_right flag
// is restricted because Mac's mice have only one button, but AFAIK
// it can be simulated with holding a special key on the keydoard.
enum input_flag_e
{
mouse_left = 1,
mouse_right = 2,
kbd_shift = 4,
kbd_ctrl = 8
};
//--------------------------------------------------------------key_code_e
// Keyboard codes. There's also a restricted set of codes that are most
// probably supported on different platforms. Any platform dependent codes
// should be converted into these ones. There're only those codes are
// defined that cannot be represented as printable ASCII-characters.
// All printable ASCII-set can be used in a regular C/C++ manner:
// ' ', 'A', '0' '+' and so on.
// Since the class is used for creating very simple demo-applications
// we don't need very rich possibilities here, just basic ones.
// Actually the numeric key codes are taken from the SDL library, so,
// the implementation of the SDL support does not require any mapping.
enum key_code_e
{
// ASCII set. Should be supported everywhere
key_backspace = 8,
key_tab = 9,
key_clear = 12,
key_return = 13,
key_pause = 19,
key_escape = 27,
// Keypad
key_delete = 127,
key_kp0 = 256,
key_kp1 = 257,
key_kp2 = 258,
key_kp3 = 259,
key_kp4 = 260,
key_kp5 = 261,
key_kp6 = 262,
key_kp7 = 263,
key_kp8 = 264,
key_kp9 = 265,
key_kp_period = 266,
key_kp_divide = 267,
key_kp_multiply = 268,
key_kp_minus = 269,
key_kp_plus = 270,
key_kp_enter = 271,
key_kp_equals = 272,
// Arrow-keys and stuff
key_up = 273,
key_down = 274,
key_right = 275,
key_left = 276,
key_insert = 277,
key_home = 278,
key_end = 279,
key_page_up = 280,
key_page_down = 281,
// Functional keys. You'd better avoid using
// f11...f15 in your applications if you want
// the applications to be portable
key_f1 = 282,
key_f2 = 283,
key_f3 = 284,
key_f4 = 285,
key_f5 = 286,
key_f6 = 287,
key_f7 = 288,
key_f8 = 289,
key_f9 = 290,
key_f10 = 291,
key_f11 = 292,
key_f12 = 293,
key_f13 = 294,
key_f14 = 295,
key_f15 = 296,
// The possibility of using these keys is
// very restricted. Actually it's guaranteed
// only in win32_api and win32_sdl implementations
key_numlock = 300,
key_capslock = 301,
key_scrollock = 302,
// Phew!
end_of_key_codes
};
//------------------------------------------------------------------------
// A predeclaration of the platform dependent class. Since we do not
// know anything here the only we can have is just a pointer to this
// class as a data member. It should be created and destroyed explicitly
// in the constructor/destructor of the platform_support class.
// Although the pointer to platform_specific is public the application
// cannot have access to its members or methods since it does not know
// anything about them and it's a perfect incapsulation :-)
class platform_specific;
//----------------------------------------------------------ctrl_container
// A helper class that contains pointers to a number of controls.
// This class is used to ease the event handling with controls.
// The implementation should simply call the appropriate methods
// of this class when appropriate events occur.
class ctrl_container
{
enum max_ctrl_e { max_ctrl = 64 };
public:
//--------------------------------------------------------------------
ctrl_container() : m_num_ctrl(0), m_cur_ctrl(-1) {}
//--------------------------------------------------------------------
void add(ctrl& c)
{
if(m_num_ctrl < max_ctrl)
{
m_ctrl[m_num_ctrl++] = &c;
}
}
//--------------------------------------------------------------------
bool in_rect(double x, double y)
{
unsigned i;
for(i = 0; i < m_num_ctrl; i++)
{
if(m_ctrl[i]->in_rect(x, y)) return true;
}
return false;
}
//--------------------------------------------------------------------
bool on_mouse_button_down(double x, double y)
{
unsigned i;
for(i = 0; i < m_num_ctrl; i++)
{
if(m_ctrl[i]->on_mouse_button_down(x, y)) return true;
}
return false;
}
//--------------------------------------------------------------------
bool on_mouse_button_up(double x, double y)
{
unsigned i;
bool flag = false;
for(i = 0; i < m_num_ctrl; i++)
{
if(m_ctrl[i]->on_mouse_button_up(x, y)) flag = true;
}
return flag;
}
//--------------------------------------------------------------------
bool on_mouse_move(double x, double y, bool button_flag)
{
unsigned i;
for(i = 0; i < m_num_ctrl; i++)
{
if(m_ctrl[i]->on_mouse_move(x, y, button_flag)) return true;
}
return false;
}
//--------------------------------------------------------------------
bool on_arrow_keys(bool left, bool right, bool down, bool up)
{
if(m_cur_ctrl >= 0)
{
return m_ctrl[m_cur_ctrl]->on_arrow_keys(left, right, down, up);
}
return false;
}
//--------------------------------------------------------------------
bool set_cur(double x, double y)
{
unsigned i;
for(i = 0; i < m_num_ctrl; i++)
{
if(m_ctrl[i]->in_rect(x, y))
{
if(m_cur_ctrl != int(i))
{
m_cur_ctrl = i;
return true;
}
return false;
}
}
if(m_cur_ctrl != -1)
{
m_cur_ctrl = -1;
return true;
}
return false;
}
private:
ctrl* m_ctrl[max_ctrl];
unsigned m_num_ctrl;
int m_cur_ctrl;
};
//---------------------------------------------------------platform_support
// This class is a base one to the apllication classes. It can be used
// as follows:
//
// class the_application : public agg::platform_support
// {
// public:
// the_application(unsigned bpp, bool flip_y) :
// platform_support(bpp, flip_y)
// . . .
//
// //override stuff . . .
// virtual void on_init()
// {
// . . .
// }
//
// virtual void on_draw()
// {
// . . .
// }
//
// virtual void on_resize(int sx, int sy)
// {
// . . .
// }
// // . . . and so on, see virtual functions
//
//
// //any your own stuff . . .
// };
//
//
// int agg_main(int argc, char* argv[])
// {
// the_application app(pix_format_rgb24, true);
// app.caption("AGG Example. Lion");
//
// if(app.init(500, 400, agg::window_resize))
// {
// return app.run();
// }
// return 1;
// }
//
// The reason to have agg_main() instead of just main() is that SDL
// for Windows requires including SDL.h if you define main(). Since
// the demo applications cannot rely on any platform/library specific
// stuff it's impossible to include SDL.h into the application files.
// The demo applications are simple and their use is restricted, so,
// this approach is quite reasonable.
//
class platform_support
{
public:
enum max_images_e { max_images = 16 };
// format - see enum pix_format_e {};
// flip_y - true if you want to have the Y-axis flipped vertically.
platform_support(pix_format_e format, bool flip_y);
virtual ~platform_support();
// Setting the windows caption (title). Should be able
// to be called at least before calling init().
// It's perfect if they can be called anytime.
void caption(const char* cap);
const char* caption() const { return m_caption; }
//--------------------------------------------------------------------
// These 3 methods handle working with images. The image
// formats are the simplest ones, such as .BMP in Windows or
// .ppm in Linux. In the applications the names of the files
// should not have any file extensions. Method load_img() can
// be called before init(), so, the application could be able
// to determine the initial size of the window depending on
// the size of the loaded image.
// The argument "idx" is the number of the image 0...max_images-1
bool load_img(unsigned idx, const char* file);
bool save_img(unsigned idx, const char* file);
bool create_img(unsigned idx, unsigned width=0, unsigned height=0);
//--------------------------------------------------------------------
// init() and run(). See description before the class for details.
// The necessity of calling init() after creation is that it's
// impossible to call the overridden virtual function (on_init())
// from the constructor. On the other hand it's very useful to have
// some on_init() event handler when the window is created but
// not yet displayed. The rbuf_window() method (see below) is
// accessible from on_init().
bool init(unsigned width, unsigned height, unsigned flags);
int run();
//--------------------------------------------------------------------
// The very same parameters that were used in the constructor
pix_format_e format() const { return m_format; }
bool flip_y() const { return m_flip_y; }
unsigned bpp() const { return m_bpp; }
//--------------------------------------------------------------------
// The following provides a very simple mechanism of doing someting
// in background. It's not multithreading. When wait_mode is true
// the class waits for the events and it does not ever call on_idle().
// When it's false it calls on_idle() when the event queue is empty.
// The mode can be changed anytime. This mechanism is satisfactory
// to create very simple animations.
bool wait_mode() const { return m_wait_mode; }
void wait_mode(bool wait_mode) { m_wait_mode = wait_mode; }
//--------------------------------------------------------------------
// These two functions control updating of the window.
// force_redraw() is an analog of the Win32 InvalidateRect() function.
// Being called it sets a flag (or sends a message) which results
// in calling on_draw() and updating the content of the window
// when the next event cycle comes.
// update_window() results in just putting immediately the content
// of the currently rendered buffer to the window without calling
// on_draw().
void force_redraw();
void update_window();
//--------------------------------------------------------------------
// So, finally, how to draw anythig with AGG? Very simple.
// rbuf_window() returns a reference to the main rendering
// buffer which can be attached to any rendering class.
// rbuf_img() returns a reference to the previously created
// or loaded image buffer (see load_img()). The image buffers
// are not displayed directly, they should be copied to or
// combined somehow with the rbuf_window(). rbuf_window() is
// the only buffer that can be actually displayed.
rendering_buffer& rbuf_window() { return m_rbuf_window; }
rendering_buffer& rbuf_img(unsigned idx) { return m_rbuf_img[idx]; }
//--------------------------------------------------------------------
// Returns file extension used in the implementation for the particular
// system.
const char* img_ext() const;
//--------------------------------------------------------------------
void copy_img_to_window(unsigned idx)
{
if(idx < max_images && rbuf_img(idx).buf())
{
rbuf_window().copy_from(rbuf_img(idx));
}
}
//--------------------------------------------------------------------
void copy_window_to_img(unsigned idx)
{
if(idx < max_images)
{
create_img(idx, rbuf_window().width(), rbuf_window().height());
rbuf_img(idx).copy_from(rbuf_window());
}
}
//--------------------------------------------------------------------
void copy_img_to_img(unsigned idx_to, unsigned idx_from)
{
if(idx_from < max_images &&
idx_to < max_images &&
rbuf_img(idx_from).buf())
{
create_img(idx_to,
rbuf_img(idx_from).width(),
rbuf_img(idx_from).height());
rbuf_img(idx_to).copy_from(rbuf_img(idx_from));
}
}
//--------------------------------------------------------------------
// Event handlers. They are not pure functions, so you don't have
// to override them all.
// In my demo applications these functions are defined inside
// the the_application class (implicit inlining) which is in general
// very bad practice, I mean vitual inline methods. At least it does
// not make sense.
// But in this case it's quite appropriate bacause we have the only
// instance of the the_application class and it is in the same file
// where this class is defined.
virtual void on_init();
virtual void on_resize(int sx, int sy);
virtual void on_idle();
virtual void on_mouse_move(int x, int y, unsigned flags);
virtual void on_mouse_button_down(int x, int y, unsigned flags);
virtual void on_mouse_button_up(int x, int y, unsigned flags);
virtual void on_key(int x, int y, unsigned key, unsigned flags);
virtual void on_ctrl_change();
virtual void on_draw();
virtual void on_post_draw(void* raw_handler);
//--------------------------------------------------------------------
// Adding control elements. A control element once added will be
// working and reacting to the mouse and keyboard events. Still, you
// will have to render them in the on_draw() using function
// render_ctrl() because platform_support doesn't know anything about
// renderers you use. The controls will be also scaled automatically
// if they provide a proper scaling mechanism (all the controls
// included into the basic AGG package do).
// If you don't need a particular control to be scaled automatically
// call ctrl::no_transform() after adding.
void add_ctrl(ctrl& c) { m_ctrls.add(c); c.transform(m_resize_mtx); }
//--------------------------------------------------------------------
// Auxiliary functions. trans_affine_resizing() modifier sets up the resizing
// matrix on the basis of the given width and height and the initial
// width and height of the window. The implementation should simply
// call this function every time when it catches the resizing event
// passing in the new values of width and height of the window.
// Nothing prevents you from "cheating" the scaling matrix if you
// call this function from somewhere with wrong arguments.
// trans_affine_resizing() accessor simply returns current resizing matrix
// which can be used to apply additional scaling of any of your
// stuff when the window is being resized.
// width(), height(), initial_width(), and initial_height() must be
// clear to understand with no comments :-)
void trans_affine_resizing(int width, int height)
{
if(m_window_flags & window_keep_aspect_ratio)
{
//double sx = double(width) / double(m_initial_width);
//double sy = double(height) / double(m_initial_height);
//if(sy < sx) sx = sy;
//m_resize_mtx = trans_affine_scaling(sx, sx);
trans_viewport vp;
vp.preserve_aspect_ratio(0.5, 0.5, aspect_ratio_meet);
vp.device_viewport(0, 0, width, height);
vp.world_viewport(0, 0, m_initial_width, m_initial_height);
m_resize_mtx = vp.to_affine();
}
else
{
m_resize_mtx = trans_affine_scaling(
double(width) / double(m_initial_width),
double(height) / double(m_initial_height));
}
}
trans_affine& trans_affine_resizing() { return m_resize_mtx; }
const trans_affine& trans_affine_resizing() const { return m_resize_mtx; }
double width() const { return m_rbuf_window.width(); }
double height() const { return m_rbuf_window.height(); }
double initial_width() const { return m_initial_width; }
double initial_height() const { return m_initial_height; }
unsigned window_flags() const { return m_window_flags; }
//--------------------------------------------------------------------
// Get raw display handler depending on the system.
// For win32 its an HDC, for other systems it can be a pointer to some
// structure. See the implementation files for detals.
// It's provided "as is", so, first you should check if it's not null.
// If it's null the raw_display_handler is not supported. Also, there's
// no guarantee that this function is implemented, so, in some
// implementations you may have simply an unresolved symbol when linking.
void* raw_display_handler();
//--------------------------------------------------------------------
// display message box or print the message to the console
// (depending on implementation)
void message(const char* msg);
//--------------------------------------------------------------------
// Stopwatch functions. Function elapsed_time() returns time elapsed
// since the latest start_timer() invocation in millisecods.
// The resolutoin depends on the implementation.
// In Win32 it uses QueryPerformanceFrequency() / QueryPerformanceCounter().
void start_timer();
double elapsed_time() const;
//--------------------------------------------------------------------
// Get the full file name. In most cases it simply returns
// file_name. As it's appropriate in many systems if you open
// a file by its name without specifying the path, it tries to
// open it in the current directory. The demos usually expect
// all the supplementary files to be placed in the current
// directory, that is usually coincides with the directory where
// the executable is. However, in some systems (BeOS) it's not so.
// For those kinds of systems full_file_name() can help access files
// preserving commonly used policy.
// So, it's a good idea to use in the demos the following:
// FILE* fd = fopen(full_file_name("some.file"), "r");
// instead of
// FILE* fd = fopen("some.file", "r");
const char* full_file_name(const char* file_name);
public:
platform_specific* m_specific;
ctrl_container m_ctrls;
// Sorry, I'm too tired to describe the private
// data membders. See the implementations for different
// platforms for details.
private:
platform_support(const platform_support&);
const platform_support& operator = (const platform_support&);
pix_format_e m_format;
unsigned m_bpp;
rendering_buffer m_rbuf_window;
rendering_buffer m_rbuf_img[max_images];
unsigned m_window_flags;
bool m_wait_mode;
bool m_flip_y;
char m_caption[256];
int m_initial_width;
int m_initial_height;
trans_affine m_resize_mtx;
};
}
#endif