Re: [Ekiga-devel-list] new XVideo patch
- From: Matthias Schneider <ma30002000 yahoo de>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] new XVideo patch
- Date: Tue, 21 Nov 2006 21:52:51 +0100 (CET)
Hello Jan, what you have seen was rather my last (not serious) attempt for positioning the window.
Here is what I know: the video->allocation.{x,y} do mark the upper left corner of the video
widget, it is perfectly ok that these are relative coordinates since the XVWindows also treats its
coordinates relative to its parent window (rootWindow, in this case the video-widget). ACtually I
also noticed that I do create the double-lined frame a little bit two big...
However I do notice 2 points here:
- why is the main ekiga window resizable? it wasnt int 2.0.3 and also many of the icons do appear
sometimes in a rather strange fashion. also resizing this window would mean that I have to catch
this event and reposition the XVWindow....
- I havent yet understood the reason for having the 2 frames around the video widget in gdk. This
is calculated in gm_mw_create_pixbuf_with_frame. I could redo this calculations in order to get
from the upper left edge of the video widget and get the video window coordinates but I do not
know if this will be the final presentation. I also would like to ask, isnt the
zframe =
gdk_pixbuf_scale_simple (frame,
(int) ((picture_width + frame_border * 2) * (zoom * frame_ratio)),
(int) ((picture_height + frame_border * 2) * (zoom * frame_ratio)),
GDK_INTERP_BILINEAR);
operation not a very nasty (in means of cpu power) scaling operation that gets done every frame
even if zoom = 1 when GDK performance shouldnt be hit that much? I know from experience that every
scaling operation in software slows down more than the complexest of all codec... I personally
dont like the double frame so much - however one effort to mitigate the performance issue may be
to store a scaled version once the zoom factor/image size is changed or use a non-scaling approach
for drawing the double-lined border... (Sorry I did not have time to test this, this is only me
speaking from experience)
To sumarize: I think I could get the correct window position calculated - however at first I would
like to raise the two mentioned issues and gain some more knowledge about them.,..
Good night,
Matthias
--- Jan Schampera <jan schampera web de> schrieb:
> On Sun, 19 Nov 2006 22:28:49 +0100 (CET)
> Matthias Schneider <ma30002000 yahoo de> wrote:
>
> > - The position of the embedded video window is not yet correct. I
> > have not yet found out how to calculate its position...
>
> Hi Matthias!
>
> When you calculate the coordinates out of the video widget given by the
> main, do you realize that video->allocation.{x,y} are relative to the
> parent allocation? It looks like you treat them as absolute. I may be
> wrong, anyways, it was a hard day.
>
> J.
>
> --
> I know life sometimes can get tough! and I know life sometimes can be a
> drag! But people, we have been given a gift, we have been given a road
> And that roads name is... rock and roll!
> KISS in "God gave Rock'n'Roll to you"
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
>
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]