+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: [LINUX] XBMC for Linux port to ARM architecture CPU and SoC chips? (/showthread.php?tid=35139)
- CrashX - 2010-04-20
vane.xbmc Wrote:Hi,
running arm_camelot on a beagleboard, the background images last between 1 and 2 seconds to be loaded so you can change the menu (videos, pictures, system...) without see the background . Could this inconvenience be improved?
Or simply the HW can't make it better?
Images with less resolution can be loaded smoothly.
Also, the pointer is very slow and is a very small png image. Isn't it should go faster?
Regards,
vane.
Which skin are you using ? Try using PM3.HD
- vane.xbmc - 2010-04-22
CrashX Wrote:Which skin are you using ? Try using PM3.HD
Ok, If I use PM3.HD it goes faster because it doesn't have pictures with big resolution.
Thank you.
XBMC mouse - vane.xbmc - 2010-04-26
topfs2 Wrote:Well it involves quite a bit of alteration to get speedy. Most importantly the GPU is to weak, so less needs to be rendered, alot less. To get less rendering you would need to render the complex static content into framebuffers so those complex renderings goes down to a single textured alpha blended quad instead of the hundreds it may be (text for instance)
Ok, thank you, I'll try to do that.
Another problem is the XBMC mouse. It's very slow and I don't understand why, because it is a small png image, it sould be rendered quickly, isn't it?
- topfs2 - 2010-04-26
vane.xbmc Wrote:Ok, thank you, I'll try to do that.
Another problem is the XBMC mouse. It's very slow and I don't understand why, because it is a small png image, it sould be rendered quickly, isn't it?
the actual mousecursor is drawn quick, problem is that its not the only thing that gets drawn. Everything is drawn each frame, Google gameloop design.
Cheers,
Tobias
- djhalmy - 2010-05-05
Hi McGeagh:
I was watching the video xbmc on arm2 in youtube (http://www.youtube.com/watch?v=CYq7f-CrnOc) and it resulted me very strange that arm-camelot had runned with the line code of WinSystemEGL.cpp :
Code:
int options = [b]SDL_OPENGL;[/b]
if (m_bFullScreen)
options |= SDL_FULLSCREEN;
else
options |= SDL_RESIZABLE;
if ((m_SDLSurface = SDL_SetVideoMode(m_nWidth, m_nHeight, 0, [b]options[/b])))
{
RefreshEGLContext();
return true;
}because arm-camelot use OpenGL ES and the option SDL_OPENGL creates a OPENGL context instead of OPENGL ES context.
In order to run arm-camelot in my beagle a had to remove the option OPENGL and now, I don't Know if the GUI uses HW acelerator because I get only 6-7 fps in the GUI and the CPU is to 98 %.
With flag SDL_OPENGL activated, my screen is black. Did you get running arm-camelot in the video of youtube with that flag activated?
What is your opinion about this? Is possible to change SDL to create the window (using X) and
keeping SDL to administer the events ? The other option could be use the library libsdl-gles but I don't know what is its state and if it supportes OGLES2.0.
Thanks for your time.
- vane.xbmc - 2010-05-06
davilla Wrote:SDL_OPENGLES only works under the svn trunk of SDL 1.3. OpenGL/ES support was added for running SDL under the iPhone. There have not been any stable releases of SDL 1.3 so you would be targeting a moving svn if you used SDL 1.3. Is SDL 1.3 the "extended SDL library" that you are talking about ?
Hi,
could we get any improvement running XBMC using SDL 1.3 (with opengl es)?
I've successfully run XBMC without SDL to create the windows, but it does not handle events (mouse and keyboard). I suppose it needs the m_SDLSurface created by SDL_SetVideoMode to do that.
I did:
eglGetDisplay((EGLNativeDisplayType)0)
instead of
eglGetDisplay((EGLNativeDisplayType)m_dpy)
I'm thinking about using SDL 1.3 with opengles or not to use SDL at all, like you have said in other posts.
Regards,
Vane.
- davilla - 2010-05-06
The plan is to remove SDL depends and handle events ourselves.
- McGeagh - 2010-05-07
djhalmy:
that video is rather old and isnt actually the arm-camelot branch, but the old, and now removed, xbmc_on_arm branch... Still, its always had the SDL_GL flag set, and does work. Indeed when you remove that flag, it reverts to cpu based rendering and is v slow, so leave it in! (for now)
arm-camelot does currently run fine on the beagleboard, and mostly works. gui renders completely correctly (except screensaver dim). So a bit weird how it doesnt for you.
vane.xbmc:
No real need for sdl1.3, as sdl1.2 does work (unless ive been dreaming it!) and as davilla has pointed out, it will be taken out back and shot to death eventually
- djhalmy - 2010-05-10
Quote: davilla : m_SDLSurface returned is zero. So something wrong with SDL and OpenGL/ES
Hi davilla:
Have you solved the problem with the flag SDL_OPENGL in the function SDL_SetvideoMode ?
To run xbmc in my beagle I had to remove it and without that it looks like it reverts to cpu based rendering.
Thanks
Quote: Mcgeagh : that video is rather old and isnt actually the arm-camelot branch, but the old, and now removed, xbmc_on_arm branch... Still, its always had the SDL_GL flag set, and does work. Indeed when you remove that flag, it reverts to cpu based rendering and is v slow, so leave it in! (for now)
arm-camelot does currently run fine on the beagleboard, and mostly works. gui renders completely correctly (except screensaver dim). So a bit weird how it doesnt for you.
Hi Mcgeagh :
I am using distro Angstrom. Do you Know if my problem could be related with that?
Other strange thing is that in order to be cpu rendering in the beagle it is running better than in a PC to 2,7 Ghz using software rendering. doesn't Is it very strange??
Thanks for your answer.
- McGeagh - 2010-05-10
Depends... if by that you mean on the PC, you compiled with --disable-gl, then itll use software fallbacks for everything... dead slow, even on beagle (1 frame, every 5seconds?)
But if you just remove that SDL_OPENGL flag in that one place, then its a different matter. It will switch to software based SDL parts only, the rest will still be hardware accelerated.
This is likely going to be just handling the windowing, and possibly the swpascreen.
This will cause it to be cpu intensive, and slow the rendering, but not be as slow as full sw rendering...
I cannot say whether your issue lies with Angstrom as i have not tested it on that in a very long time. Its real quick and easy to setup it with ubuntu (on another sd card, so can switch back to angstrom) so give it a try and find out.
- skanimal - 2010-05-11
Xbmc for iPad
?
- davilla - 2010-05-11
skanimal Wrote:Xbmc for iPad
Stop that, it just annoys the goldfish.
- spiff - 2010-05-11
you can take that ipad of yours and stuff it where it belongs.
- McGeagh - 2010-05-11
whats with everyones obsession with that?
I would even go out of my way to purposely not do anything with anything apple related.
They make aesthetically nice tech, but is limited to hell... not sure about you, but i want my gadgets to DO stuff, and more importantly, do it the way I want it to, not just look pretty.
Form over function is NOT acceptable.
Reminds me of the motorola razr.... shit phone, but every one had to have one because it was fashionable.
Rant over.
- djhalmy - 2010-05-12
Hi
Quote: Mcgeagh : This is likely going to be just handling the windowing, and possibly the swpascreen.
What do you refer when you write swapscreen?.
Other thing : Comparing normal xbmc 9.11 in pc with arm-camelot in beagle I detected one difference in the GUI using the skin Confluence.
Using arm-camelot When you are in main window (home.xml) if you put the focus in system item you see the reflection of another subwindow (setting, file manager, profiles, sistem info) behind. Using normal xbmc 9.11 in pc you don't see this relection.
Could that be because in RenderSystemGLES.cpp there are functions to replace functions GL and they aren't optimized ? I suppose that these functions (MatrixGLES.cpp) are not HW accelerated
Could these functions of MatrixGLES.cpp be implemented using glsl code ??
Thanks