Graphics::Primitive::Driver(3pm) | User Contributed Perl Documentation | Graphics::Primitive::Driver(3pm) |
Graphics::Primitive::Driver - Role for driver implementations
What good is a library agnostic intermediary representation of graphical components if you can't feed them to a library specific implementation that turns them into drawings? Psht, none!
To write a driver for Graphics::Primitive implement this role.
my $c = Graphics::Primitive::Component->new({ origin => Geometry::Primitive::Point->new({ x => $x, y => $y }), width => 500, height => 350 });
When a path is added to the internal list via do, it is stored in the paths attribute as a hashref. The hashref has two keys: path and op. The path is, well, the path. The op is the operation provided to do. As canvases are just lists of paths you should consult the next section as well.
Paths are lists of primitives. Primitives are all descendants of Geometry::Shape and therefore have point_start and point_end. These two attributes allow the chaining of primitives. To draw a path you should iterate over the primitives, drawing each.
When you pull each path from the arrayref you should pull it's accompanying hints via get_hint (the indexes match). The hint may provide you with additional information:
Only this class or the driver itself should call methods starting with an underscore, as this interface may change.
Cory Watson, "<gphat@cpan.org>"
Copyright 2008-2010 by Cory G Watson.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
2022-06-14 | perl v5.34.0 |