On 2007-05-30 01:55, Carsten Haitzler (The Rasterman) wrote:
> thats interesting. i swear i handled this properly. when videos are of ODD
> width size this would happen - mplayer and xine both had the bug but i
> made
> that work in emotion/evas - the code literally checks to see if the plane
> poi
Evas recently got YV12 support for images, which is in the GL engine is
accelerated via fragment program. Is adding YUY2 support theoretically
possible?
I guess this is less of an evas question and more of an OpenGL one, and
I'm asking if it's possible to construct a fragment program to handle
YU
On Mon, 2007-28-05 at 21:14 -0500, Nathan Ingersoll wrote:
> Evas_Coord was originally defined as a float, so you may see a few
> remnants like that. Also there was originally support for non
> one-to-one mappings of evas coordinate space to world coordinates.
Do you know the reason for the change
On Tue, 2007-08-05 at 15:28 -0400, Jason Tackaberry wrote:
>3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect
> impossible (or possible, but lame). However this is probably not
> practical without a big evas rewrite.
I was thinking about this ...
Hi,
There seems to be a problem with the GL engine given an evas image in
YUV colorspace when setting data via evas_object_image_data_set() if the
stride of the data does not equal the image's width. (By this I mean
that where data is treated as an array of pointers, given any two
consecutive poi
On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote:
> Motivation to do so is to have clip border as fade out instead of hard
> "cut". We need it for our software, Canola, but talking to Freevo guys
> show the same problem.
This is definitely a big deal for us (Freevo). We've been resorting to
ug
Hi,
Recently (as of 0.9.9.036 I think), evas no longer has the ability to
have a viewport size that differs from the output size. This was a
feature we (Freevo) relied on -- what was the motivation for removing
this feature? Is there any alternative method to achieve equivalent
functionality in
On Thu, 2006-09-14 at 06:55 +, [EMAIL PROTECTED] wrote:
> Much ado about gradients, but hopefully all this will make
> it easier to work with grads in current edje and otherwise.
Forgive me for chiming in when I haven't read the full thread nor
grokked the context, but does any of your w
On Mon, 2006-04-03 at 23:53 -0400, Jason Tackaberry wrote:
>movie.osd.add_child(kaa.canvas.Text("Hello E!"))
>movie.osd.show() # osd is hidden by default
Oh, another cool feature of kaa.canvas is the animation engine. So if
you want to fade the OSD in:
# Start f
On Tue, 2006-04-04 at 11:36 +0900, Carsten Haitzler wrote:
> yup - i know :) i have handled this in emotion and it does it just fine (thank
> god) thus dvd playback using emotion is a doodle :) xine does the heavy
> lifting
> - emotion just plugs the right things in the right places. since for me
On Tue, 2006-04-04 at 12:03 +0900, Carsten Haitzler wrote:
> a bit of a pipe dream as it's either
> 1. really expensive as you basically have to render N times more pixels and
Doesn't opengl support subpixel resolution?
What I'm trying to do is a Ken Burns type effect for a photo slideshow,
where
I would definitely love to see subpixel resolution (for scaling and
positioning of objects, particularly). Is this on the radar? Or is it
a complete pipe dream?
Cheers,
Jason
---
This SF.Net email is sponsored by xPML, a groundbreaking scrip
On Tue, 2006-04-04 at 08:47 +0900, Carsten Haitzler wrote:
> thus a copy to the final display device anyway. in your case i'm not sure why
> you need a larger rowstride anyway?
I'm not sure either. When I discovered the bug last night I asked
myself the same question, and just changed all the cod
On Mon, 2006-04-03 at 12:35 +0900, Carsten Haitzler wrote:
> note: if your buffer width != width * 4 - then evas does an extra copy from a
> temporary buffer to the final buffer. evas takes lots of shortcuts when it can
> and will render directly to the dest buffer if it meets requirements (ARGB32,
On Mon, 2006-04-03 at 12:22 +0900, Carsten Haitzler wrote:
> stop finding all the corner cases i don't ever use! :):):)
ROFL. :)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web
On Mon, 2006-04-03 at 08:51 +0900, Carsten Haitzler wrote:
> there was - i never finished off the BGRA code for the buffer canvas :) i
> never
> used it - and i think this was the first case of someone using it :)
And only purely by accident, because I thought BGRA32 was the native
pixel format.
I've encountered another bug. This one exists with ARGB32 but not
BGRA32.
If the row stride given in the info struct (dest_buffer_row_bytes) is
not equal to the output width * 4, nothing ends up getting rendered to
the canvas (it is completely empty).
See attached test case.
Cheers,
Jason.
#inc
On Sun, 2006-04-02 at 13:40 -0400, Jason Tackaberry wrote:
> Pixel values still wrong, but at least now it's zeroing the alpha at the
> old location after object move.
>
> So there seems to be two separate problems with BGRA32 here.
Just to follow up, I saw raster had commit
On Sun, 2006-04-02 at 15:18 +, [EMAIL PROTECTED] wrote:
> In your example, you have an output size of (640, 480), and
> a viewport at (0,0) of size (800, 600).
> You then create a rectangle object of *canvas* coordinate
> size (700, 50) and move it to the *canvas* position (0, 300).
Hi raster,
On Sun, 2006-04-02 at 16:15 +0900, Carsten Haitzler wrote:
> are you using BGRA in freevo too? you know that invovles evas having to do a
> byteswap for all rendering as its the opposite color-order to evas's
> internals?
> (which is ARGB) ?
Evas's internals are ARGB? Well isn't that
On Sat, 2006-04-01 at 22:30 -0500, Jason Tackaberry wrote:
> If the viewport size matches the output size or is smaller then it seems
> to be fine. It's only when the viewport is larger than the output size.
Actually, this may not be entirely accurate. I'm seeing a couple ca
Hi raster,
On Sun, 2006-04-02 at 10:27 +0900, Carsten Haitzler wrote:
> how are you using it? using ecore_evas? are you using the update region
> callback by hand (not ecore_evas) ? i am looking at the code here - if u ask
> for EVAS_ENGINE_BUFFER_DEPTH_ARGB32 depth - it will zero out the alpha ch
Hi all,
I've been quite out of the loop for a while (new job, relocated), so I
haven't been following evas changes very well. I've just upgraded from
0.9.9.022 to 026 and I've noticed a change in behavior in the buffer
canvas with respect to transparent (or rather I guess "undefined")
backgrounds
On Mon, 2006-01-23 at 21:15 +0900, Carsten Haitzler wrote:
> dependencies even if they arene't using e17 or e apps (just using evas for
> some
> specific fucntionality like a dvd/pvr system - eg freevo, where it only
> displays in the framebuffer... just for starters.)
Actually, we (Freevo) use t
On Fri, 2005-12-30 at 17:31 +0100, Kim Woelders wrote:
> I think you are right that something is wrong somewhere around here.
> However, this patch breaks stuff for certain fonts (w becomes too small,
> IIRC).
Ok. I have to plead a bit of ignorance when it comes to font metrics.
But if your pro
On Fri, 2005-12-23 at 12:22 -0500, Jason Tackaberry wrote:
> The problem is that for some fonts, characters that render below the
> baseline (for example, the letter 'g') get clipped by a couple pixels.
> Not all fonts are affected, like for example Vera or Tahoma, but some
&g
On Wed, 2005-12-28 at 13:35 +0200, [EMAIL PROTECTED] wrote:
> What drives me crazy is that I suspect that the problem is trivial
> and I missing something that you guys would laugh at!!
A quick look and my first suggestion is to set the font with a call to
evas_object_text_font_set().
Cheers,
Jas
I am getting a segfault when calling evas_object_image_data_set() using
the directfb engine. Looking at the source for the engine, I can see
what the problem is, but I'm not entirely sure how to fix it.
The problem is that evas_engine_directfb_image_new_from_copied_data()
frees the image_data buf
Having upgraded from Imlib2 1.2.1.004 to 1.2.1.009, I've observed a font
rendering bug that was present in the 1.2.0 series (which had been fixed
when I upgraded to 1.2.1.004) has returned. There is no problem with
004, but as of 005 it seems to have returned.
The problem is that for some fonts,
On Mon, 2005-12-19 at 12:32 +0900, Carsten Haitzler wrote:
> it excercizes i think pretty much all of tb's features. especially check the
> textblock test code out.
Yes, this helps very nicely. Thanks, raster.
Cheers,
Jason.
signature.asc
Description: This is a digitally signed message part
There's little documentation that I can find on evas textblock,
particularly the syntax for markup text. Would someone be kind enough
to outline the basics to get me started?
Thanks,
Jason.
signature.asc
Description: This is a digitally signed message part
On Sun, 2005-12-18 at 10:31 -0500, Jason Tackaberry wrote:
> The attached simple program which positions an image to negative
> coordinates (-80, -60). This crashes Evas cvs, as well as 0.9.9.022:
Hrm, something funky happened with my email client and it didn't attach
properly. Here
The attached simple program which positions an image to negative
coordinates (-80, -60). This crashes Evas cvs, as well as 0.9.9.022:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209002272 (LWP 25589)]
evas_common_tilebuf_add_redraw (tb=0x87375d8, x=0, y=-28800, w=0
On Sun, 2005-12-18 at 00:19 +0900, Carsten Haitzler wrote:
> but where does evas fit in there? evas has its own yuv (yv12) import mechanism
> and eventually i want to merge all that down into the engine level so in
> theory
> it can hw accel if possible or simply sw convert - so you just provide y
On Sat, 2005-12-17 at 18:27 +0900, Carsten Haitzler wrote:
> technically - yes. it's a bug. it's due to the fact that the routines dont
> have
> a special case for multiple when alpha doesnt contain sensible data (filling
> it
> in with an assumed 0xff) :)
I argued this on mplayer-dev, and provi
I'm using an external library that generates a BGR32 image. The source
image is only 24bpp, so the alpha channel is all zeroed. So, when I add
the image to an evas canvas and use evas_object_image_data_set, I pass 0
to evas_object_image_alpha_set. My assumption is that this merely
indicates to E
On Tue, 2005-12-06 at 15:32 +0900, Carsten Haitzler wrote:
> yeah - we ALSO need arbitratry clipping to any object, with an added option of
> pre-rendering all objects to be clipped by a clipper to a tmp buffer, unlike
I'd settle for extending the current approach to support gradient
objects as we
On Sat, 2005-10-15 at 09:33 +1000, Daniel Kasak wrote:
> the KHTML people are pissed off with Apple ( who use KHTML in Safari )
> for not following the 'spirit' of the GPL and detailing their changes in
> change logs, patches, etc, and actually participating in the community.
If I remember the KHT
On Tue, 2005-07-26 at 16:28 +0500, Boldin Pavel wrote:
> I though joke is EXACTLY name of this field.
I remember in a past life in my computational theory class the term
"pumping lemma." Just because it sounds like a joke doesn't mean it is
one.
> It can be called ``type" or ``FOURCC" like in ot
On Thu, 2005-06-23 at 11:24 +0900, Carsten Haitzler wrote:
> read it - fixed it up a bit (used copy functions as this will use mmx/sse
> functions if available) :)
Great! Tested and works. With this and the evas_free() fix I'm a happy
camper.
One of the main things I'm missing from evas is some
The attached patch fixes a segfault in evas_free() when no output method
has been set.
Cheers,
Jason.
--- evas.orig/src/lib/canvas/evas_main.c2005-06-17 22:09:09.0
-0400
+++ evas/src/lib/canvas/evas_main.c 2005-06-17 22:09:01.0 -0400
@@ -150,9 +150,12 @@
e->obs
Hi,
Attached is a patch to engines/buffer/evas_outbuf.c which allows evas to
write to BGR32 buffers. I've been sitting on this patch for a while now
because I'm not very familiar with evas's code, so I'm not sure if this
is the optimal way to do it. Nevertheless, the code is trivial enough
that
42 matches
Mail list logo
