9:41 p.m.
This patch implements animated gifs, but also as a consequence optimizes
the redisplay handling of glyphs and subwindows somewhat which I hope to
use in optimizing layout handling.
I have only tested this with one animated glyph so I'm guessing there may
be some bizarre formats that are not handled correctly. I'm hoping I
haven't broken gutter display in the process, the way I'm doing things now
is more correct but also slightly different and therefore has the potential
for new bugs.
This patch was almost entirely coded on the train.
andy
1999-10-05 Andy Piper <andy(a)xemacs.org>
* redisplay.c: new state flags, subwindows_state_changed and
subwindows_state_changed set.
(redisplay_window): use them.
(redisplay_device): ditto.
(redisplay_without_hooks): ditto.
(redisplay_frame): ditto. Reset subwindow cachels if
subwindows_changed is set.
(redisplay_window): call mark_glyph_cachels_as_clean after
redisplaying.
* redisplay-x.c (x_output_x_pixmap): select correct
pixmap image for display depending on the currently selected
slice.
* redisplay-output.c (compare_runes): check dirtiness when
checking RUNE_DGLYPH runes.
(compare_display_blocks): relax invalidation of display blocks
since we can now detect whether individual glyphs have changed or
not.
* redisplay-msw.c (mswindows_output_dibitmap): select correct
bitmap image for display depending on the currently selected
slice.
* glyphs.h (struct Lisp_Image_Instance): add a dirty flag.
(IMAGE_INSTANCE_DIRTYP): new macro.
(XIMAGE_INSTANCE_DIRTYP): ditto.
(MARK_IMAGE_INSTANCE_CHANGED): ditto.
(GLYPH_DIRTYP): ditto.
(XGLYPH_DIRTYP): ditto.
(MARK_GLYPH_CHANGED): ditto.
(GLYPH_CACHEL_DIRTYP): ditto.
(struct glyph_cachel): add a dirty flag.
* glyphs.c (update_frame_subwindows): Don't update on
glyphs_changed.
(glyph_animated_timeout_mapper): new function. Map over the
instance cache lookinng for animated images to update.
(Fglyph_animated_timeout_handler): new function. Lisp callback for
handling animated image timeout events.
(disable_glyph_animated_timeout): new function. Add the animated
image timeout.
(disable_glyph_animated_timeout): new function. Remove the
animated image timeout.
(syms_of_glyphs): initialize Qglyph_animated_timeout_handler and
friends.
(vars_of_glyphs): initialize Vglyph_animated_ticker.
(image_instance_equal): add the currently displayed slice.
(image_instance_hash): ditto.
(allocate_glyph): initialize dirty flag.
(glyph_width): rename glyph -> glyph_or_image.
(glyph_height_internal): ditto.
(glyph_dirty_p): new function. Determine whether the image
instance in the domain and/or glyph is dirty.
(set_glyph_dirty_p): set the dirtiness.
(update_glyph_cachel_data): take dirtiness into account. Pass the
image instance we are interested in to glyph_width and friends.
(get_glyph_cachel_index): make non-static. Always call
update_glyph_cachel_data.
(mark_glyph_cachels_as_not_updated): meaningless formatting
change.
(mark_glyph_cachels_as_clean): new function. Clean dirtiness from
glyph cachels.
* glyphs-x.h (struct x_image_instance_data): change
pixmap to a list of pixmaps.
(IMAGE_INSTANCE_X_PIXMAP_SLICE): new macro.
(IMAGE_INSTANCE_X_PIXMAP_SLICES): ditto.
(XIMAGE_INSTANCE_X_PIXMAP_SLICE): ditto.
(XIMAGE_INSTANCE_X_PIXMAP_SLICES): ditto.
* glyphs-x.c (x_finalize_image_instance): make sure multi pixmap
images get deleted properly.
(init_image_instance_from_x_image): add slices paramater and use
it to initialize x_image_instance_data correctly.
(image_instance_add_x_image): new function. Add new pixmaps to our
set of instantiated pixmaps for an image. Used by animated images.
(x_init_image_instance_from_eimage): add a slices
parameter. Instantiate all images from the eimage.
(x_xpm_instantiate): update use of
init_image_instance_from_x_image.
(init_image_instance_from_xbm_inline): ditto.
(x_initialize_pixmap_image_instance): add slices paramater and use
it to allocate x_image_instance_data correctly.
* glyphs-msw.h (struct mswindows_image_instance_data): change
bitmap to a list of bitmaps.
(IMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICE): new macro.
(IMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICES): ditto.
(XIMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICE): ditto.
(XIMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICES): ditto.
* glyphs-msw.c (init_image_instance_from_dibitmap): add slices
paramater and use it to initialize mswindows_image_instance_data
correctly.
(image_instance_add_dibitmap): new function. Add new bitmaps to
our set of instantiated bitmaps for an image. Used by animated
images.
(mswindows_init_image_instance_from_eimage): add a slices
parameter. Instantiate all images from the eimage.
(mswindows_xpm_instantiate): update use of
init_image_instance_from_dibitmap.
(bmp_instantiate): ditto.
(init_image_instance_from_xbm_inline): ditto.
(mswindows_finalize_image_instance): make sure all the bitmap
slices get deleted.
(mswindows_initialize_dibitmap_image_instance): add slices
paramater and use it to allocate mswindows_image_instance_data
correctly.
* glyphs-eimage.c (jpeg_instantiate): give extra paramter to
init_image_instance_from_eimage.
(png_instantiate): ditto.
(tiff_instantiate): ditto.
(gif_instantiate): allocate bitmaps for all gif slices not just
the first one.
* device.h (struct device): add subwindows_state_changed flag.
(MARK_DEVICE_SUBWINDOWS_STATE_CHANGED): new macro.
(MARK_DEVICE_FRAMES_GLYPHS_CHANGED): ditto.
* console.h (struct console_methods): add a slice parameter to
init_image_instance_from_eimage_method.
* redisplay.c (create_string_text_block): Allow buffer to be nil
without crashing.
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
6:39 a.m.
Congrats! Looks good. But there are some problems. In particular, you don't
handle multiple animated gifs properly. (In fact, there will be a timeout leak
in such a case!) You need to have each separate animated gif have its own
timeout, which you store as a field in the image instance, and the timeout's
argument should be the image instance, not a device. This allows for animated
gifs with different time delays (is this not a property of the gif itself? You
hardcode it at 100ms) and would also allow each gif to be stopped independently
of the others. You also really need to implement this stop ability, or people
will go crazy. You should do this using a weak list or hashtable of all the
animated gifs, which you map over. You might also think about providing a lisp
interface to retrieve this list, and possibly other similar lists of extant
image instances. (Somebody, probably whose last name is Perry, is going to want
this.)
Also, why do you have a separate IMAGE_WIDGET_MASK and IMAGE_LAYOUT_MASK?
These are really one and the same.
ben
Andy Piper wrote:
This patch implements animated gifs, but also as a consequence
optimizes
the redisplay handling of glyphs and subwindows somewhat which I hope to
use in optimizing layout handling.
I have only tested this with one animated glyph so I'm guessing there may
be some bizarre formats that are not handled correctly. I'm hoping I
haven't broken gutter display in the process, the way I'm doing things now
is more correct but also slightly different and therefore has the potential
for new bugs.
This patch was almost entirely coded on the train.
andy
1999-10-05 Andy Piper <andy(a)xemacs.org>
* redisplay.c: new state flags, subwindows_state_changed and
subwindows_state_changed set.
(redisplay_window): use them.
(redisplay_device): ditto.
(redisplay_without_hooks): ditto.
(redisplay_frame): ditto. Reset subwindow cachels if
subwindows_changed is set.
(redisplay_window): call mark_glyph_cachels_as_clean after
redisplaying.
* redisplay-x.c (x_output_x_pixmap): select correct
pixmap image for display depending on the currently selected
slice.
* redisplay-output.c (compare_runes): check dirtiness when
checking RUNE_DGLYPH runes.
(compare_display_blocks): relax invalidation of display blocks
since we can now detect whether individual glyphs have changed or
not.
* redisplay-msw.c (mswindows_output_dibitmap): select correct
bitmap image for display depending on the currently selected
slice.
* glyphs.h (struct Lisp_Image_Instance): add a dirty flag.
(IMAGE_INSTANCE_DIRTYP): new macro.
(XIMAGE_INSTANCE_DIRTYP): ditto.
(MARK_IMAGE_INSTANCE_CHANGED): ditto.
(GLYPH_DIRTYP): ditto.
(XGLYPH_DIRTYP): ditto.
(MARK_GLYPH_CHANGED): ditto.
(GLYPH_CACHEL_DIRTYP): ditto.
(struct glyph_cachel): add a dirty flag.
* glyphs.c (update_frame_subwindows): Don't update on
glyphs_changed.
(glyph_animated_timeout_mapper): new function. Map over the
instance cache lookinng for animated images to update.
(Fglyph_animated_timeout_handler): new function. Lisp callback for
handling animated image timeout events.
(disable_glyph_animated_timeout): new function. Add the animated
image timeout.
(disable_glyph_animated_timeout): new function. Remove the
animated image timeout.
(syms_of_glyphs): initialize Qglyph_animated_timeout_handler and
friends.
(vars_of_glyphs): initialize Vglyph_animated_ticker.
(image_instance_equal): add the currently displayed slice.
(image_instance_hash): ditto.
(allocate_glyph): initialize dirty flag.
(glyph_width): rename glyph -> glyph_or_image.
(glyph_height_internal): ditto.
(glyph_dirty_p): new function. Determine whether the image
instance in the domain and/or glyph is dirty.
(set_glyph_dirty_p): set the dirtiness.
(update_glyph_cachel_data): take dirtiness into account. Pass the
image instance we are interested in to glyph_width and friends.
(get_glyph_cachel_index): make non-static. Always call
update_glyph_cachel_data.
(mark_glyph_cachels_as_not_updated): meaningless formatting
change.
(mark_glyph_cachels_as_clean): new function. Clean dirtiness from
glyph cachels.
* glyphs-x.h (struct x_image_instance_data): change
pixmap to a list of pixmaps.
(IMAGE_INSTANCE_X_PIXMAP_SLICE): new macro.
(IMAGE_INSTANCE_X_PIXMAP_SLICES): ditto.
(XIMAGE_INSTANCE_X_PIXMAP_SLICE): ditto.
(XIMAGE_INSTANCE_X_PIXMAP_SLICES): ditto.
* glyphs-x.c (x_finalize_image_instance): make sure multi pixmap
images get deleted properly.
(init_image_instance_from_x_image): add slices paramater and use
it to initialize x_image_instance_data correctly.
(image_instance_add_x_image): new function. Add new pixmaps to our
set of instantiated pixmaps for an image. Used by animated images.
(x_init_image_instance_from_eimage): add a slices
parameter. Instantiate all images from the eimage.
(x_xpm_instantiate): update use of
init_image_instance_from_x_image.
(init_image_instance_from_xbm_inline): ditto.
(x_initialize_pixmap_image_instance): add slices paramater and use
it to allocate x_image_instance_data correctly.
* glyphs-msw.h (struct mswindows_image_instance_data): change
bitmap to a list of bitmaps.
(IMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICE): new macro.
(IMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICES): ditto.
(XIMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICE): ditto.
(XIMAGE_INSTANCE_MSWINDOWS_BITMAP_SLICES): ditto.
* glyphs-msw.c (init_image_instance_from_dibitmap): add slices
paramater and use it to initialize mswindows_image_instance_data
correctly.
(image_instance_add_dibitmap): new function. Add new bitmaps to
our set of instantiated bitmaps for an image. Used by animated
images.
(mswindows_init_image_instance_from_eimage): add a slices
parameter. Instantiate all images from the eimage.
(mswindows_xpm_instantiate): update use of
init_image_instance_from_dibitmap.
(bmp_instantiate): ditto.
(init_image_instance_from_xbm_inline): ditto.
(mswindows_finalize_image_instance): make sure all the bitmap
slices get deleted.
(mswindows_initialize_dibitmap_image_instance): add slices
paramater and use it to allocate mswindows_image_instance_data
correctly.
* glyphs-eimage.c (jpeg_instantiate): give extra paramter to
init_image_instance_from_eimage.
(png_instantiate): ditto.
(tiff_instantiate): ditto.
(gif_instantiate): allocate bitmaps for all gif slices not just
the first one.
* device.h (struct device): add subwindows_state_changed flag.
(MARK_DEVICE_SUBWINDOWS_STATE_CHANGED): new macro.
(MARK_DEVICE_FRAMES_GLYPHS_CHANGED): ditto.
* console.h (struct console_methods): add a slice parameter to
init_image_instance_from_eimage_method.
* redisplay.c (create_string_text_block): Allow buffer to be nil
without crashing.
------------------------------------------------------------------------
Name: anim.patch
anim.patch Type: Plain Text (text/plain)
Encoding: quoted-printable
------------------------------------------------------------------------
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
10:37 a.m.
At 10:39 PM 10/6/99 -0700, Ben Wing wrote:
Congrats! Looks good. But there are some problems. In particular,
you
don't
handle multiple animated gifs properly. (In fact, there will be a
timeout
leak
in such a case!) You need to have each separate animated gif have its
own
timeout, which you store as a field in the image instance, and the timeout's
argument should be the image instance, not a device. This allows for
animated
Yes I know. I will fix.
gifs with different time delays (is this not a property of the gif
itself?
You
hardcode it at 100ms) and would also allow each gif to be stopped
independently
It is but I have no idea what property.
of the others. You also really need to implement this stop ability, or
people
will go crazy. You should do this using a weak list or hashtable of all the
animated gifs, which you map over. You might also think about providing a
lisp
interface to retrieve this list, and possibly other similar lists of
extant
image instances. (Somebody, probably whose last name is Perry, is going to
want
this.)
Ok, I'll look into it.
Also, why do you have a separate IMAGE_WIDGET_MASK and
IMAGE_LAYOUT_MASK?
These are really one and the same.
I don't think so - the image data is different.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
5:11 p.m.
You also really need to implement this stop ability, or people
>will go crazy.
For what it's worth, if XEmacs starts supporting animated GIF's I'd
like to see a lisp variable which controls the maximum number of
drawing repeats. The value 0 would represent a desire for no
animations.
I use special proxy server while browsing which gives me the above
capabilities. I'd hate to take a step backwards.
--
Antonio Freixas
tonyf(a)ims.com
(503) 626-5433
1:55 a.m.
Here's some info on the delay property. It's in one of the extensions (graphic
control extension). You should also pay attention to the Netscape loop extension,
which indicates whether and how the animation should loop.
First, the GIF89a spec:
23. Graphic Control Extension.
a. Description. The Graphic Control Extension contains parameters used
when processing a graphic rendering block. The scope of this extension is
the first graphic rendering block to follow. The extension contains only
one data sub-block.
This block is OPTIONAL; at most one Graphic Control Extension may precede
a graphic rendering block. This is the only limit to the number of
Graphic Control Extensions that may be contained in a Data Stream.
b. Required Version. 89a.
c. Syntax.
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Graphic Control Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | | | | <Packed Fields> See below
+---------------+
2 | | Delay Time Unsigned
+- -+
3 | |
+---------------+
4 | | Transparent Color Index Byte
+---------------+
+---------------+
0 | | Block Terminator Byte
+---------------+
<Packed Fields> = Reserved 3 Bits
Disposal Method 3 Bits
User Input Flag 1 Bit
Transparent Color Flag 1 Bit
i) Extension Introducer - Identifies the beginning of an extension
16
block. This field contains the fixed value 0x21.
ii) Graphic Control Label - Identifies the current block as a
Graphic Control Extension. This field contains the fixed value
0xF9.
iii) Block Size - Number of bytes in the block, after the Block
Size field and up to but not including the Block Terminator. This
field contains the fixed value 4.
iv) Disposal Method - Indicates the way in which the graphic is to
be treated after being displayed.
Values : 0 - No disposal specified. The decoder is
not required to take any action.
1 - Do not dispose. The graphic is to be left
in place.
2 - Restore to background color. The area used by the
graphic must be restored to the background color.
3 - Restore to previous. The decoder is required to
restore the area overwritten by the graphic with
what was there prior to rendering the graphic.
4-7 - To be defined.
v) User Input Flag - Indicates whether or not user input is
expected before continuing. If the flag is set, processing will
continue when user input is entered. The nature of the User input
is determined by the application (Carriage Return, Mouse Button
Click, etc.).
Values : 0 - User input is not expected.
1 - User input is expected.
When a Delay Time is used and the User Input Flag is set,
processing will continue when user input is received or when the
delay time expires, whichever occurs first.
vi) Transparency Flag - Indicates whether a transparency index is
given in the Transparent Index field. (This field is the least
significant bit of the byte.)
Values : 0 - Transparent Index is not given.
1 - Transparent Index is given.
vii) Delay Time - If not 0, this field specifies the number of
hundredths (1/100) of a second to wait before continuing with the
processing of the Data Stream. The clock starts ticking immediately
after the graphic is rendered. This field may be used in
conjunction with the User Input Flag field.
viii) Transparency Index - The Transparency Index is such that when
encountered, the corresponding pixel of the display device is not
modified and processing goes on to the next pixel. The index is
present if and only if the Transparency Flag is set to 1.
ix) Block Terminator - This zero-length data block marks the end of
17
the Graphic Control Extension.
d. Extensions and Scope. The scope of this Extension is the graphic
rendering block that follows it; it is possible for other extensions to
be present between this block and its target. This block can modify the
Image Descriptor Block and the Plain Text Extension.
e. Recommendations.
i) Disposal Method - The mode Restore To Previous is intended to be
used in small sections of the graphic; the use of this mode imposes
severe demands on the decoder to store the section of the graphic
that needs to be saved. For this reason, this mode should be used
sparingly. This mode is not intended to save an entire graphic or
large areas of a graphic; when this is the case, the encoder should
make every attempt to make the sections of the graphic to be
restored be separate graphics in the data stream. In the case where
a decoder is not capable of saving an area of a graphic marked as
Restore To Previous, it is recommended that a decoder restore to
the background color.
ii) User Input Flag - When the flag is set, indicating that user
input is expected, the decoder may sound the bell (0x07) to alert
the user that input is being expected. In the absence of a
specified Delay Time, the decoder should wait for user input
indefinitely. It is recommended that the encoder not set the User
Input Flag without a Delay Time specified.
Second, some code from a program called gifsicle:
/* extension byte table:
0x01 plain text extension
0xCE name*
0xF9 graphic control extension
0xFE comment extension
0xFF application extension
*/
static void
write_graphic_control_extension(Gif_Image *gfi, Gif_Writer *grr)
{
byte packed = 0;
gifputbyte('!', grr);
gifputbyte(0xF9, grr);
gifputbyte(4, grr);
if (gfi->transparent >= 0) packed |= 0x01;
packed |= (gfi->disposal & 0x07) << 2;
gifputbyte(packed, grr);
gifputunsigned(gfi->delay, grr);
gifputbyte((byte)gfi->transparent, grr);
gifputbyte(0, grr);
}
static void
blast_data(byte *data, int len, Gif_Writer *grr)
{
while (len > 0) {
int s = len > 255 ? 255 : len;
gifputbyte(s, grr);
gifputblock(data, s, grr);
data += s;
len -= s;
}
gifputbyte(0, grr);
}
static void
write_name_extension(char *id, Gif_Writer *grr)
{
gifputbyte('!', grr);
gifputbyte(0xCE, grr);
blast_data((byte *)id, strlen(id), grr);
}
static void
write_comment_extensions(Gif_Comment *gfcom, Gif_Writer *grr)
{
int i;
for (i = 0; i < gfcom->count; i++) {
gifputbyte('!', grr);
gifputbyte(0xFE, grr);
blast_data((byte *)gfcom->str[i], gfcom->len[i], grr);
}
}
static void
write_netscape_loop_extension(u_int16_t value, Gif_Writer *grr)
{
gifputblock((byte *)"!\xFF\x0BNETSCAPE2.0\x03\x01", 16, grr);
gifputunsigned(value, grr);
gifputbyte(0, grr);
}
Third, some docs on the Netscape loop extension:
Netscape Navigator has an Application Extension Block that tells Navigator to loop
the entire GIF file. The Netscape block
MUST APPEAR IMMEDIATELY AFTER THE GLOBAL COLOR TABLE OF THE LOGICAL SCREEN
DESCRIPTOR. Only Navigator 2.0 Beta4 or better will recognize this Extension
block. The block is 19 bytes long composed
of: (note: hexadecimal equivalent supplied for programmers)
byte 1 : 33 (hex 0x21) GIF Extension code
byte 2 : 255 (hex 0xFF) Application Extension Label
byte 3 : 11 (hex (0x0B) Length of Application Block
(eleven bytes of data to follow)
bytes 4 to 11 : "NETSCAPE"
bytes 12 to 14 : "2.0"
byte 15 : 3 (hex 0x03) Length of Data Sub-Block
(three bytes of data to follow)
byte 16 : 1 (hex 0x01)
bytes 17 to 18 : 0 to 65535, an unsigned integer in
lo-hi byte format. This indicate the
number of iterations the loop should
be executed.
bytes 19 : 0 (hex 0x00) a Data Sub-block Terminator.
Andy Piper wrote:
At 10:39 PM 10/6/99 -0700, Ben Wing wrote:
>Congrats! Looks good. But there are some problems. In particular, you
don't
>handle multiple animated gifs properly. (In fact, there will be a timeout
leak
>in such a case!) You need to have each separate animated gif have its own
>timeout, which you store as a field in the image instance, and the timeout's
>argument should be the image instance, not a device. This allows for
animated
Yes I know. I will fix.
>gifs with different time delays (is this not a property of the gif itself?
You
>hardcode it at 100ms) and would also allow each gif to be stopped
independently
It is but I have no idea what property.
>of the others. You also really need to implement this stop ability, or people
>will go crazy. You should do this using a weak list or hashtable of all the
>animated gifs, which you map over. You might also think about providing a
lisp
>interface to retrieve this list, and possibly other similar lists of extant
>image instances. (Somebody, probably whose last name is Perry, is going to
want
>this.)
Ok, I'll look into it.
>Also, why do you have a separate IMAGE_WIDGET_MASK and IMAGE_LAYOUT_MASK?
>These are really one and the same.
I don't think so - the image data is different.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
1:57 a.m.
New subject: Animated gif patch (2)
The distinction between layouts and widgets makes no sense, so you should combine
the different data required. Consider a grouping widget. Is this a layout or a
widget? It draws, like a widget, but has children, like a layout. Same for a tab
widget, properly implemented. It draws, handles input, has children, and makes
choices about how to lay them out.
ben
Andy Piper wrote:
At 10:39 PM 10/6/99 -0700, Ben Wing wrote:
>Congrats! Looks good. But there are some problems. In particular, you
don't
>handle multiple animated gifs properly. (In fact, there will be a timeout
leak
>in such a case!) You need to have each separate animated gif have its own
>timeout, which you store as a field in the image instance, and the timeout's
>argument should be the image instance, not a device. This allows for
animated
Yes I know. I will fix.
>gifs with different time delays (is this not a property of the gif itself?
You
>hardcode it at 100ms) and would also allow each gif to be stopped
independently
It is but I have no idea what property.
>of the others. You also really need to implement this stop ability, or people
>will go crazy. You should do this using a weak list or hashtable of all the
>animated gifs, which you map over. You might also think about providing a
lisp
>interface to retrieve this list, and possibly other similar lists of extant
>image instances. (Somebody, probably whose last name is Perry, is going to
want
>this.)
Ok, I'll look into it.
>Also, why do you have a separate IMAGE_WIDGET_MASK and IMAGE_LAYOUT_MASK?
>These are really one and the same.
I don't think so - the image data is different.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9179
days inactive
9182
days old
5 comments
3 participants
participants (3)
-
Andy Piper -
Antonio Freixas -
Ben Wing