34 replies to this topic

[bacicciosat]

No no we don't need stratospheric effects but more nice menu and listbox are surely normal in current state of arts.

E2 graphics seems a work never completed, there are too many graphical objects in e1 than in e2.

For sure it is a develop side never evolved.

[MiLo]

All the BCM chips have OpenGL support, even the old 7025. But the manufacturers probably never paid to be able to use it, so that's why there is no support for it. It could well be that the mysterious ioctl calls in E2 are using a small subset of those video calls, they're certainly much faster if they have enough pixels to make up for the ioctl overhead.

Enigma2 rendering is mostly limited by its skin system. Nothing is preventing the box from running QT or X11.

[bacicciosat]

All the BCM chips have OpenGL support, even the old 7025. But the manufacturers probably never paid to be able to use it, so that's why there is no support for it. It could well be that the mysterious ioctl calls in E2 are using a small subset of those video calls, they're certainly much faster if they have enough pixels to make up for the ioctl overhead.

Enigma2 rendering is mostly limited by its skin system. Nothing is preventing the box from running QT or X11.

 

Maybe you are talking about 2D OpenGL.

But now we have OpenGL ES 2.0 3D GPU with BCM7424 (duo2).

 

But ok apart of 3d grphics do you agree or not that enigma2 graphic is poor and a little bit incomplete and should be improved ?

[pop_eye]

Maybe you are talking about 2D OpenGL.

But now we have OpenGL ES 2.0 3D GPU with BCM7424 (duo2).

 

But ok apart of 3d grphics do you agree or not that enigma2 graphic is poor and a little bit incomplete and should be improved ?

Actually don`t understand what is too poor for you in 2D environment.

Have you seen the ruDream Infinity image ? I think it is python all the way.

 

Find a platform with OpenGL and get the directFb full implementation with video driver and you got yourself the suitable HW for the 3d task.

Edited by pop_eye, 19 November 2013 - 16:27.

[MiLo]

Maybe you are talking about 2D OpenGL.
But now we have OpenGL ES 2.0 3D GPU with BCM7424 (duo2).

I meant the kind of OpenGL you can use to play Quake on. Which is totally unrelated to what is required to run Android these days.

They all have some support for OpenGL, but most of it is pretty basic.

Not that it matters anyhow, because you cannot use the OpenGL hardware without support from the manufacturer.

But ok apart of 3d grphics do you agree or not that enigma2 graphic is poor and a little bit incomplete and should be improved?

I have no idea what I would want to use 3D for in a GUI for a PVR.

Yes, the graphics and especially the UI parts of E2 are "poor". If I rewrite it, people will yell at me because they cannot use skins anymore.

[bacicciosat]

Maybe you are talking about 2D OpenGL.
But now we have OpenGL ES 2.0 3D GPU with BCM7424 (duo2).

I meant the kind of OpenGL you can use to play Quake on. Which is totally unrelated to what is required to run Android these days.

They all have some support for OpenGL, but most of it is pretty basic.

Not that it matters anyhow, because you cannot use the OpenGL hardware without support from the manufacturer.

>But ok apart of 3d grphics do you agree or not that enigma2 graphic is poor and a little bit incomplete and should be improved?

I have no idea what I would want to use 3D for in a GUI for a PVR.

Yes, the graphics and especially the UI parts of E2 are "poor". If I rewrite it, people will yell at me because they cannot use skins anymore.

 

 

It seems to me that is not only poor but a little bit incomplete.

Look at a comparison with enigma1.

We had in e1 that wonderful sync function to flush all the graphics before to render new objects.

This is missed in e2 and we had to be creative with all those tricks like timers to prevent the annoyng modal window issue.

And focus ? Do you remeber the e1 focus mechanism facility in design windows with multibple buttons and lists ?

There are such important and basical functions never implemented in e2 that is ridicoulus to talk about 3d effects.

 

Yes the skin back compatibility is a problem but is not THE problem.

A new menu system could be easly be added leaving avaialble the current.

I think the real problem is that to work to graphic side require a big amount of work and energies both from programming side and also from skin side.

And all the graphic system is too much old.

So, maybe the real problem is if is a good idea to invest time and energies in this side or to wait for something new to work in the future.

[pop_eye]

Thanks for ignoring my posting. Quite sure you can have the same level of discussion via PM.

 

On the side note...frame-buffer should be the one allowing better functionality and not enigma2.

 

enigma2 should be using the available ioctls from the framebuffer engine and having 3d extensions you can render with sprites and triple buffering.

 

I agree with Milo, the OpenGL subset was not purchased (implemented) in drivers...and thus the DirectFB is not fully implemented.

 

I can see in Opendreambox 2.0 for the dreamboxes they are using DirectFB with fusion for video rendering (just for the webkit requirement ?)

 

After drivers are exposing the needed ioctls, a 3d lib (component) can be added for enigma2 usage...and even made accessible via pyopengl.

 

Instead of adding extra garbage in enigma2 try pushing manufacturers for better drivers

Edited by pop_eye, 19 November 2013 - 22:16.

[bacicciosat]

sorry pop_eye, i have not seen ruDream image and no interest in it.

i like to know the Milo opinion about e1 and e2 gui because i remember the pli beginning many years ago with enigma1.

And i remeber that they introduced a nice volume handle in the skin.

At the times it appears to me a nice new and i still remember their egauge.cpp new graphic object in e1 gui lib.

(hope that my memory is not wrong)

[pieterg]

That was before MiLo joined us
But indeed, e1 offered more graphical freedom, simply because there was no python layer on top of it, we did everything in the 'gdi' layer, without having to worry about exporting new stuff to python.

The same could be done in e2, but it would require a lot more code to export it 'nicely' in order for the skins to use it.

[mirakels]

At the times it appears to me a nice new and i still remember their egauge.cpp new graphic object in e1 gui lib.

(hope that my memory is not wrong)

No you memory is not wrong   I added  egauge in e1. But I thought something similar is available in e2 (I did not check). How else do they make the analog clocks?

[bacicciosat]

At the times it appears to me a nice new and i still remember their egauge.cpp new graphic object in e1 gui lib.

(hope that my memory is not wrong)

No you memory is not wrong   I added  egauge in e1. But I thought something similar is available in e2 (I did not check). How else do they make the analog clocks?

 

Don't know what they use for analog clock i still use a little mod of egauge.cpp

But i still remember that the volume handler effect was really nice and i always asked myself why there weren't other implementation in this side after a so nice beginning.

[MiLo]

...How else do they make the analog clocks?

The clock hands are being drawn as a few dozen single-pixel rectangles. Blatantly ignoring the "line" function in the GDI layer.

[Robinson]

It would be interesting if such a receiver could support the following:

- 4:2:2

- ACM/VCM modulation

- 16APSK, 32APSK

 

Is this at all possible or only DVB cards can do that?

[gorski]

AZbug HD could do the 4:2:2 with OFW, maybe not with Enigma2. So, HW wise it is possible, even if we don't have a very strong HW...

 

From what I remember, the planned (but not yet done) original Ferrari STB was supposed to have the tuner capable of 4:2:2, too...

 

But... who's gonna wrap his/her knowledgeable brains around these issues?!?

[littlesat]

The tuner is capabel for 4:2:2... But the broadcom encoder isn't...