Commit Graph

26 Commits

Author SHA1 Message Date
doursse fb9313c024 * move convert function declarations to their own header file
* add vim header in the files I modified
 * fix minor warnings

i think i don't break compilation on that commit :)


SVN revision: 35058
2008-07-10 22:53:33 +00:00
Carsten Haitzler c10ccad763 static func - cedric patch
SVN revision: 32649
2007-11-13 05:58:50 +00:00
Carsten Haitzler 2ea744bc1b working on optimising software-x11 with the one-buffer persistence idea that
software-16 uses. it works and in some cases gets massive speedups (70%+) but
in a few its slowdowns (30% down) in expedite tests - why, i don't know. it
should be the same or better in all tests. disabled for now - also not
complete. < 32bpp wont' work and not sure rotation works and masks don't work
either.


SVN revision: 31928
2007-10-02 03:40:14 +00:00
Gustavo Sverzut Barbieri bd66a665b6 Use C89 prototype.
By: Brett Nash (c89-is-18-years-old-lets-use-it.patch)


SVN revision: 31695
2007-09-13 14:14:37 +00:00
Carsten Haitzler 7b392c8ce3 gustavo's patch on free an empty/unused evas.
SVN revision: 29777
2007-04-30 04:23:47 +00:00
Carsten Haitzler 5ac7b84136 pager urgent popup patch - good
evas clipouts less allocs patch - definite spedusp for when it's used heavily!


SVN revision: 29331
2007-04-04 09:55:40 +00:00
Carsten Haitzler ccc60306a0 sli is possible- but not optimal.
SVN revision: 27129
2006-11-15 16:44:34 +00:00
Carsten Haitzler 9781eb9b38 1. evas gets a pipeline with deferred rendering ability (sometimes faster,
sometimes slower)
2. --enable-pthreads will enable multi-threaded rendering (current support is
for up to 4 threads so if you have a new fanled quad core or dual cpu dual
core box or whatever you will in theory be able to max moe of its cpu grunt
with the software rendering engine. this can only be done because i added the
pipelines which means almsot entirely lock-free multithreading internally in
evas. the only locks are for fonts but with a little work i might be able to
remove some/most of those too)

for now pthreaded rendering likely will be linux only (it relies on sched.h
for setting scheduler params to force the slave threads to run on separate
cpu's as linux likes to keep them on the same cpu otherwise and thus we get
no speedups at all - only slowdowns).

aso note that it is a bit of a mixed bag. complex ops (like smooth scaling
with alpha blending) get speedups, but simple ops (like blits/fills) slow down.

this all neds examination and tweaking still - but it's a start.


SVN revision: 27098
2006-11-13 23:23:44 +00:00
Carsten Haitzler 8c93e825a8 same as previous commit.
SVN revision: 26236
2006-09-30 10:18:37 +00:00
sebastid e55f7b27b2 Functions used by modules must be EAPI
SVN revision: 25526
2006-09-06 07:33:40 +00:00
Carsten Haitzler 77e35d60a3 jose's software rendering work - slight improvements (about 5-10%). i had to
disable destination alha mmx support for text rendering (mask + color) as it
was broken in tests.


SVN revision: 22440
2006-05-02 07:28:49 +00:00
Carsten Haitzler 1adf40fbb5 actually use the sse routines!
SVN revision: 19955
2006-01-22 06:54:18 +00:00
Carsten Haitzler a0ceee8b51 i have to back out all of jose's blend changes - musch faster than
debugging/fixing and likely int he end the exact same result of fixing them.
yes - we lose performance - but it actually is correct now :) if we want to
do such radical changes- i sugegst moving to premultiplied alpha and makign a
tonne of externally tested routines in a test harness first to compare
correctness and speed in an isolated environment.


SVN revision: 18947
2005-12-11 04:55:20 +00:00
Carsten Haitzler 1b272aec90 joses's gradient work - gradient look nice. one problem jose.. USE BRACKETS!
do NOT depend on order operation precedence. it broke scaling. laos other
completely bizarre mmx things were going wrong with mm7 ending up not 0 so
i've had to force it to be 0.


SVN revision: 18811
2005-12-03 09:27:53 +00:00
Carsten Haitzler 59bbe6cf2d move pow lut table to read only shared memory
SVN revision: 18628
2005-11-24 04:40:14 +00:00
Carsten Haitzler 46e02cf8bb whitespace
SVN revision: 14889
2005-05-22 02:49:50 +00:00
Carsten Haitzler e79e53e35b i worked on a regionbuf set of code (exact rectangles). i THINK it has some
bugs... but its disabled right now and it didnt speed anything up :( but it's
there for perusal and later work anyway...


SVN revision: 13193
2005-02-05 02:30:13 +00:00
Carsten Haitzler 8c29c3d42b use mmx2 routines if we can - they are faster! (almost 3 times)
SVN revision: 10361
2004-05-26 02:45:40 +00:00
Carsten Haitzler 56c4d96737 oops - missed init func entry points. fixed.
SVN revision: 10187
2004-05-13 01:57:28 +00:00
Carsten Haitzler e2725f4690 lean down memory usage per process - now it doesnt use up 64kb it doesnt need
to... :)


SVN revision: 10153
2004-05-10 06:40:51 +00:00
rbdpngn 732d2e2836 Those changes should not have gone to cvs yet.
SVN revision: 8132
2003-12-16 17:49:45 +00:00
Carsten Haitzler 3b808bac45 1. mmx2 pixel copy and cleanup of pixel copy routines
2. gl engine cleanups. working on it.


SVN revision: 7436
2003-09-10 08:52:18 +00:00
Carsten Haitzler 246fd31846 open gl is fulyl functional now - it coudl defnitely do with optimizations
with texture upload. it does NOt check error returns anywhere from gl... this
may mean issues with LOTs of images, LARGE images etc. need to fix that later


SVN revision: 7432
2003-09-09 05:51:03 +00:00
rbdpngn 7af9c3bf45 Use the new runtime cpu detection functions to determine the correct drawing
routines. Some stubs for altivec support can be seen here, those are
unreachable code paths until the corresponding functions are complete and
committed.


SVN revision: 7191
2003-07-20 05:33:11 +00:00
Carsten Haitzler 3dc1dcbd32 the big internal function call renaming happened... and it was good.
SVN revision: 6449
2002-11-14 05:38:10 +00:00
Carsten Haitzler 56b5e15f26 code move
SVN revision: 6445
2002-11-08 08:02:15 +00:00