Enlightenment E18 Alpha Release Is Imminent

[gens]

You should try resizing windows. That just feels so much smoother on wayland. Also, remember Beryl, which by default only showed window outlines while resizing, because it was so slow?

was funny
xterm as an x app (running in rootless X ofc) caused artifacts around it while being resized
under wayland stuff like resizing and transparency, even stuff like rotating windows and zoom, work no problem no slowdown

i remember an (X) talk by Keith about moving windows that repaint themselves and how complicated it is


anyway forgot to say
gj e guys, its awsome

[raster]

did 'e' ever finally implement wireframe resize and move? I've been asking for that essential feature forever.

no. why is it essential? i've lived without forever. it's far more useful to see the content at the size you want.

[gens]

@raster

i wrote some SSE/AVX/etc loops back when
albeit in FASM

if E needs some 4x4 matrix manipulations or idk, id be willing
(lot harder in GCC inline, but id try anyway)

[raster]

@raster

i wrote some SSE/AVX/etc loops back when
albeit in FASM

if E needs some 4x4 matrix manipulations or idk, id be willing
(lot harder in GCC inline, but id try anyway)

i don't know about 4x4 matrix transforms being needed - we basically don't do them ever... (well except as part of the glsl shaders and then it's all done on gpu anyway).

but we could always do with better mmx/sse/sse3 etc. asm for the rendering code which is all simd fun...

[gens]

i don't know about 4x4 matrix transforms being needed - we basically don't do them ever... (well except as part of the glsl shaders and then it's all done on gpu anyway).

but we could always do with better mmx/sse/sse3 etc. asm for the rendering code which is all simd fun...

that is this ?

i found weston to use matrices, didn't check what for but probably transforms in cpu rendering

also im dabbling opengl 3.3 core where 4x4 matrices are better to do on cpu, for viewport and such (in the long run)

point me to a function and i'l see if i'm in over my head
simd should be np but advanced C pointer..ing can still confuse me, also the ugly GCC inline/intinsics

[raster]

that is this ?

i found weston to use matrices, didn't check what for but probably transforms in cpu rendering

also im dabbling opengl 3.3 core where 4x4 matrices are better to do on cpu, for viewport and such (in the long run)

point me to a function and i'l see if i'm in over my head
simd should be np but advanced C pointer..ing can still confuse me, also the ugly GCC inline/intinsics

yes - thats the main bit of the tree where you find that. also in the evas_op_* subdirs - thats where most of the arch-specific asm is. if you can improve on what's there... go for it! consider it a challenge. just grep for MMX and/or SSE (within #ifdef's)... you'll spot the code.

as such we dont actually do matricies at all - we aren't like weston. we just do simple plain arithmetic - we don't try a translate into a matrix - we just do x2 = x1 + n; (and same for y). as such we don't do enough of this math for it to every even be in a profile that matters. for software rendering the thing that really matters is the actual pixel bashing code as above. the only other thing i can think of right now that could be better is the rectangle math where we calculate update region by adding and subtracting rectangle regions and generating nice big lists of rects in the process... of course some simd may help - but likely this is more affected by algorithms than simd.

[gens]

yes - thats the main bit of the tree where you find that. also in the evas_op_* subdirs - thats where most of the arch-specific asm is. if you can improve on what's there... go for it! consider it a challenge. just grep for MMX and/or SSE (within #ifdef's)... you'll spot the code.

as such we dont actually do matricies at all - we aren't like weston. we just do simple plain arithmetic - we don't try a translate into a matrix - we just do x2 = x1 + n; (and same for y). as such we don't do enough of this math for it to every even be in a profile that matters. for software rendering the thing that really matters is the actual pixel bashing code as above. the only other thing i can think of right now that could be better is the rectangle math where we calculate update region by adding and subtracting rectangle regions and generating nice big lists of rects in the process... of course some simd may help - but likely this is more affected by algorithms than simd.

sounds fun
glanced a bit, some functions i see would be easy to remake in AVX/FMA, easy performance win on newer cpu's
i guess blending is intensive
while others... there's plenty of code to get acquainted with

got a rough plan, but it will take time
il post on the mailing list if/when something comes out of it

i'v been thinking for a while now about a simple network manager module that uses iw, wpa_supplicant and such (as slackware dosent package connman), so there's that too
(later using cfg80211, very much later probably)


about rectangles
yes, i also think simd wont help much when there's plenty of logic to be done and not much real number crunching
maybe some fancy algorithm with conditional MOV's to minimize branching
that sounds even more fun
(if i didnt understand it wrong, am tired now)


PS as i got you here might as well report a bug

changing in a .desktop file
Exec=/root/bin/Dwarf Fortress/startlnp
to
Exec=/root/bin/Dwarf\ Fortress/startlnp

makes e17 crash when
right click -> settings(or)contents in IBar
or starting the generic settings panel
probably more

http://pastebin.com/sr0YN7Xk

sry if its trouble reporting it here
buglist thing is down and i'm not good with reading mail

[raster]

sounds fun
glanced a bit, some functions i see would be easy to remake in AVX/FMA, easy performance win on newer cpu's
i guess blending is intensive
while others... there's plenty of code to get acquainted with

got a rough plan, but it will take time
il post on the mailing list if/when something comes out of it

i'v been thinking for a while now about a simple network manager module that uses iw, wpa_supplicant and such (as slackware dosent package connman), so there's that too
(later using cfg80211, very much later probably)


about rectangles
yes, i also think simd wont help much when there's plenty of logic to be done and not much real number crunching
maybe some fancy algorithm with conditional MOV's to minimize branching
that sounds even more fun
(if i didnt understand it wrong, am tired now)


PS as i got you here might as well report a bug

changing in a .desktop file
Exec=/root/bin/Dwarf Fortress/startlnp
to
Exec=/root/bin/Dwarf\ Fortress/startlnp

makes e17 crash when
right click -> settings(or)contents in IBar
or starting the generic settings panel
probably more

http://pastebin.com/sr0YN7Xk

sry if its trouble reporting it here
buglist thing is down and i'm not good with reading mail

maybe you'll like to file a bug:

https://phab.enlightenment.org/maniphest/

we have a long list though... so i'll have to prioritize it somewhere...

[bnolsen]

no. why is it essential? i've lived without forever. it's far more useful to see the content at the size you want.

So basically it's a don't care feature on your part which has made 'e' a don't care on my part. I can't currently think of other common desktop envirtonments that don't offer wireframe options. Some applications do not behave well atall with full resize behavior. Its not my fault those applicatoins don't work and I can't fix them other than switch on wireframe resize.

[gens]

maybe you'll like to file a bug:

https://phab.enlightenment.org/maniphest/

we have a long list though... so i'll have to prioritize it somewhere...

mhm, it gave me a SQL error 2 days ago
il do more testing then report it

for me personally this is not a problem and it is the first time i ran into it
just wanted to note