Tuesday, March 25, 2014

ASP.NET MVC Tutorials

http://www.codeproject.com/Articles/741632/Start-With-MVC-Push-Start-For-Beginners-Part 1

Part 2 http://www.codeproject.com/Articles/747868/Start-With-MVC-Push-Start-For-Beginners-Part

Hi Guys, Hope you have undergone the previous article where we learn how to start with MVC and what are prerequisites. This is continue to the article "Start With MVC - Push Start For Beginners(Part - 1)". As i promised, here you will learn about Viewing saved records, Edit Records using MVC with Entity To Sql. So Let's start.


If you have undergone the part-1 of this series, you are ready for this article else please go through the part 1. Although you can start from this article too if you are already known to MVC, still i suggest you to read the previous article at one. So lets start the "Updating In MVC" . All the best !!

Here's another one

http://www.codeproject.com/Articles/207797/Learn-MVC-Model-View-Controller-step-by-step-in#Lab 4:- Creating simple MVC data entry screen

Thursday, March 6, 2014

Intel How To Draw 3D on Android in OpenGL

see http://software.intel.com/en-us/articles/porting-opengl-games-to-android-on-intel-atom-processors-part-1

Porting OpenGL* Games to Android* on Intel® Atom™ Processors (part 1)

Great opportunity exists in porting games and other applications that make extensive use of 3D graphics through OpenGL standards to Google Android devices, including those built on the Intel® Atom™ microarchitecture because of the availability of games, game engines, and other legacy software based on OpenGL; the portability that OpenGL provides; and Android’s evolving support for OpenGL ES and C/C++. Many OpenGL-based game titles and engines are even available as open source, like Id Software’s Quake series. This two-part article shows how to begin such a project by detailing the barriers that exist to porting the rendering components of apps built on earlier versions of OpenGL to Android on Intel Atom processors. These applications can be games, game engines, or any software that uses OpenGL to construct 3D scenes or a graphical user interface (GUI). The porting of OpenGL code from desktop operating systems like Windows* and Linux* as well as apps that use the embedded versions of OpenGL ES—with or without a windowing system—is also covered.
Part 1 of this article introduces how to use OpenGL ES on the Android platform through either the software development kit (SDK) or the Android Native Development Toolkit (NDK) and how to decide which approach to use. The various OpenGL ES sample apps in the SDK and NDK are described as well as the Java* Native Interface (JNI), which allows you to combine Java and C/C++ components. How you decide whether you should target OpenGL ES version 1.1 or 2.0 is also discussed.
Part 2 will discuss the barriers that exist to porting OpenGL games you should know before undertaking such a project, including differences in OpenGL extensions, floating-point support, texture compression formats, and the GLU library. Setting up your Android development system for Intel Atom processors and getting the best possible performance from the Android virtual device emulation tools with OpenGL ES will also be covered.

Graphics on Android

You can render graphics on the Android platform in four distinct ways, each with its own strengths and limitations (see Table 1). Covering all of these options is beyond the scope of this article. Only two approaches make sense for porting OpenGL code from other platforms: the SDK Wrapper classes for OpenGL ES and the NDK for OpenGL ES development in C/C++. Regarding the other approaches, the SDK Canvas application programming interface (API) is a powerful 2D API that you can use in combination with OpenGL ES but is otherwise limited to 2D and requires new code to use.
Android’s Renderscript API did support OpenGL ES initially, but that has been deprecated in API level 16 (Jelly Bean) and should not be used for new projects. The best application for Renderscript now is to improve the performance of compute-intensive algorithms that do not require much memory allocation or data transfer, such as calculations for simulated game physics.
Table 1. The Four Ways to Render Graphics on Android
SDK Canvas APIJava and 2D graphics only
SDK Wrapper classes for OpenGL ESOpenGL ES 1.1 and 2.0 callable from Java but with JNI overhead
NDK OpenGL ESOpenGL ES 1.1 and 2.0, with native C/C++ callable from Java
Renderscript for OpenGL ESOpenGL ES support has been deprecated in API level 16
Porting OpenGL applications to early releases of Android was difficult because most legacy OpenGL code was written in C or C++ and Android only supported Java until the release of the NDK in Android 1.5 (Cupcake). OpenGL ES 1.0 and 1.1 have been supported from the beginning, but the performance was inconsistent because acceleration was optional. But Android has made tremendous strides in recent years. Support for OpenGL ES 2.0 was added to the SDK in Android 2.2 (Froyo) and to the NDK in revision 3, with expanded support for OpenGL ES extensions in NDK revision 7. OpenGL ES 2.0 is now used so extensively by Android’s own graphics framework that it’s no longer considered optional. Accelerated OpenGL ES 1.1 and 2.0 are now essential on all new Android devices, particularly as screen sizes continue to grow. Today, Android delivers consistent and reliable performance for 3D-intensive applications built on either OpenGL ES 1.1 or 2.0 code in either Java or C/C++, and developers have several options to make the porting process easier.

Using the Android Framework SDK with the OpenGL ES Wrapper Classes

The Android SDK framework provides a set of wrapper classes for the three versions of OpenGL ES that Android supports (1.0, 1.1, and 2.0). These classes allow Java code to easily call the OpenGL ES drivers in the Android system, even though the drivers execute natively. If you are creating a new OpenGL ES Android game from scratch or are willing to convert your legacy C/C++ code to Java, then this is probably the easiest path. Even though Java is designed for portability, it can be difficult to port Java apps because Android does not support the full set of established Java Platform, Standard Edition (Java SE) or Java Platform, Micro Edition (Java ME) classes, libraries, or APIs. Android’s Canvas API is a capable 2D API, but it’s unique to Android and offers no compatibility for legacy code.
Several additional classes provided by the Android SDK make using OpenGL ES easier, such as GLSurfaceView and TextureViewGLSurfaceView is similar to the SurfaceView class used with the Canvas API but with additional features specifically for OpenGL ES. It handles the required initialization of the Embedded System Graphics Library (EGL), allocates a rendering surface that Android displays at a fixed position on the screen, and threading. It also has some useful features for tracing and debugging OpenGL ES calls. You can create a new OpenGL ES application quickly by implementing just three methods for the GLSurfaceView.Renderer() interface, as detailed in Table 2.
Table 2. The Minimum Required Methods for GLSurfaceView.Renderer
onSurfaceCreated()Called once when the application starts for initialization
onSurfaceChanged()Called whenever a change occurs to the GLSurfaceView size or orientation
onDrawFrame()Called repeatedly to render each frame of the graphics scene
Beginning with Android 4.0, you can use the TextureView class instead of GLSurfaceView to provide rendering surfaces for OpenGL ES with additional capabilities, but it requires more code to use. TextureView surfaces behave as regular Views and can be used to render to off-screen surfaces. This functionality allows you to move, transform, animate, or blend TextureViews when they are composited to the screen. Or, you can use a TextureViewto combine OpenGL ES rendering with the Canvas API.
The Bitmap and GLUtils classes make it easy to create textures for OpenGL ES using the Android Canvas API or to load textures from PNG, JPG, or GIF files. Bitmaps are used to allocate rendering surfaces for Android’s Canvas API. The GLUtils class can convert images from bitmaps into OpenGL ES textures. This integration allows you to use the Canvas API to render 2D images that can then be used as textures with OpenGL ES. This is particularly useful for creating graphics elements that OpenGL ES does not provide, like GUI widgets and text fonts. But, of course, new Java code is required to exploit these features.
The Bitmap class was designed primarily for use with the Canvas API, and it has some serious limitations when used to load textures for OpenGL ES. The Canvas API follows the Porter-Duff specification for alpha blending, and Bitmap optimizes images with per-pixel alpha by storing them in the premultiplied format (A, R*A, G*A, B*A). This is great for Porter-Duff but not for OpenGL, which requires a non-premultiplied (ARGB) format. This means that the Bitmap class can only be used with textures that are completely opaque (or have no per-pixel alpha). Three-dimensional games typically require textures with per-pixel alpha, in which case you must avoid using bitmaps and load textures from a byte array or through the NDK, instead.
Another issue is that Bitmaps only support loading images from the PNG, JPG, or GIF formats, whereas OpenGL games typically use compressed texture formats that are decoded by the GPU and are often proprietary to the GPU architecture, such as ETC1 and PVRTC. Bitmap and GLUtils do not support any proprietary compressed texture formats or mipmapping. Because these features are used heavily by most 3D games, this represents a serious barrier to porting legacy OpenGL games to Android with the SDK. Until Google resolves these problems, the best solution is to avoid using theBitmap and GLUtils classes to load textures. Texture formats are discussed further in the section, “Texture Compression Formats.”
The Android ApiDemos contain a sample app named StaticTriangleRenderer that demonstrates how to load an opaque texture from a PNG resource file using the GLES10 wrapper for OpenGL ES 1.0, GLSurfaceViewBitmap, and GLUtils classes. A similar version named GLES20TriangleRendereruses the GLES20 wrapper class for OpenGL ES 2.0, instead. These sample apps make good starting points for developing OpenGL ES games if you are targeting the Android Framework SDK using the wrapper classes. Don’t use the original version, named TriangleRenderer, because it uses a wrapper for an older version of the OpenGL ES bindings for Java named javax.microedition.khronos.opengles. Google created the new bindings to provide a static interface for OpenGL ES specifically for Android. These static bindings offer better performance, expose more OpenGL ES features, and provide a programming model that is closer to how OpenGL ES is used with C/C++, which may help with code reuse.
The Android Framework SDK provides support for OpenGL ES through several bindings for Java from Google and Khronos, as detailed in Table 3.
Table 3. Summary of Wrapper Classes for OpenGL ES and Sample Apps
Java Bindings for OpenGL ESDescriptionSample Apps
javax.microedition.khronos.eglKhronos standard definition
javax.microedition.khronos.openglesKhronos standard definitionTriangleRenderer, Kube, CubeMap
android.openglAndroid-specific static interfaces
The Android-specific static bindings offer better performance and should be used instead of the Khronos bindings whenever possible. The static bindings provide corresponding wrapper classes for all versions of OpenGL ES available for application development on Android. Table 4 summarizes these classes.
Table 4. Summary of Android Wrapper Classes for OpenGL ES and Sample Apps
API VersionJava ClassSample Apps
OpenGL ES 1.0android.opengl.GLES10StaticTriangleRenderer, CompressedTexture
OpenGL ES 1.0android.opengl.GLES10Ext
OpenGL ES 1.1android.opengl.GLES11
OpenGL ES 1.1android.opengl.GLES11Ext
OpenGL ES 2.0android.opengl.GLES20GLES20TriangleRenderer, BasicGLSurfaceView, HelloEffects
These wrapper classes are designed such that most OpenGL ES calls in legacy C/C++ code can be converted to Java by simply prefixing OpenGL ES function and symbol names with a wrapper class of the appropriate API version. See the examples in Table 5.
Table 5. Examples of Editing OpenGL ES Calls from C to Java
C LanguageJava Language
glDrawArrays(GL_TRIANGLES, 0, count)GLES11.glDrawArrays(GLES11.GL_TRIANGLES, 0, count)
glDrawArrays(GL_TRIANGLES, 0, count)GLES20.glDrawArrays(GLES20.GL_TRIANGLES, 0, count)
Porting OpenGL games to Android using these wrapper classes has three significant limitations: the overhead of the Java Virtual Machine and the JNI and the work required to convert legacy C/C++ code to Java. Java is an interpreted language, and all Java code on Android runs on the Dalvik virtual machine, which executes more slowly than compiled C/C++ code. Because the OpenGL ES drivers always execute natively, every call to an OpenGL ES function through these wrappers incurs the overhead of the JNI, limiting the performance of your game’s graphics rendering. The more OpenGL ES calls your application makes, the greater the impact of the JNI overhead. Fortunately, OpenGL ES is well designed to help minimize the number of calls typically required in performance-critical rendering loops. If performance is a problem, you always have the option of moving performance-critical code to C/C++ with the NDK. But, of course, if your code began as C/C++, it might be best to start with the NDK in the first place.
Whether you should convert C/C++ code to Java depends on the details of your particular project. If the amount of C/C++ code is relatively small and well understood and you don’t want to push the performance envelope, then converting it to Java may be reasonable. Otherwise, if the amount of C/C++ code is large and not well understood and you do want to push the envelope, then consider using the NDK.

Using the Android NDK

Google added the NDK to Android in June 2009 to allow apps to use C/C++ code running natively, which offers better performance than Java. And because most legacy OpenGL code is written in C or C++, the NDK provides an easier path for porting applications, especially when the amount of C/C++ code is so large that converting it all to Java is not practical. This is actually the main reason Google decided to release the NDK publicly—to make it easier to port OpenGL games to Android. Because of these advantages, the NDK is becoming the dominate approach for implementing apps that require fast graphics on Android.
The NDK lets you compile C/C++ code to Linux shared object libraries, which are statically linked to your Android app. Libraries are built using GNU tools, which are provided in the NDK release package from Google, and you can run the tools on Windows, Mac OS* X, or Linux development systems using the Eclipse* integrated development environment or a command-line interface. This toolchain supports three processor architectures: ARM, Intel Atom (x86), and MIPS. Although the full power of C/C++ is available, most Linux APIs are not. In fact, the APIs that are supported directly include little more than OpenGL ES, OpenMAX* AL, OpenSL ES*, zlib, and Linux file I/O, which Google terms the Stable APIs. However, documentation is provided on how to port other Linux libraries into your NDK project as needed.
The NDK gives you the flexibility to partition code between Java and C/C++ as appropriate for your application. The NDK supports a mechanism for calling C/C++ code from Java called the Java Native Interface. But, significant overhead is associated with JNI calls, so it’s important to partition applications carefully using native code to minimize the number of calls through the JNI. Typically, most OpenGL ES code should remain in C/C++ for the best performance and ease of porting, while new Java code can be written to use GLSurfaceView and other SDK classes to manage app life cycle events and support other game functions. Android began supporting the JNI for Intel Atom processors beginning with NDK revision 6b.
The NDK supports OpenGL ES 1.1 and 2.0 and provides sample apps for both versions that also demonstrate how to combine C functions with Java using the JNI. These apps differ in how their code is partitioned between Java and C and in how they are threaded. They all use the NDK and native C code, but the native-media sample app retains all of its OpenGL ES code in Java, whereas san-angeles and native-activity have all of their OpenGL ES code in C and hello-gl2 splits its EGL and OpenGL ES code between Java and C. It’s best to avoid using the hello-gl2 sample because of this split and because it does not use the preferred method to configure GLSurfaceView for OpenGL ES 2.0 surfaces, which is to callsetEGLContextClientVersion(2). See Table 6.
Table 6. Summary of OpenGL ES Sample Apps in the NDK
API UsedSample AppSDK/NDK Partitioning
OpenGL ES 1.1san-angelesAll EGL and OpenGL ES code is C.
OpenGL ES 1.1native-activityAll code is in C and uses the NativeActivity class.
OpenGL ES 2.0hello-gl2EGL setup is in Java, and OpenGL ES code is C.
OpenGL ES 2.0native-mediaAll EGL and OpenGL ES code is Java.
Even though it does not use OpenGL ES, the bitmap-plasma sample is also interesting because it demonstrates how to use the jnigraphics library to implement native functions that directly access the pixels of Android bitmaps.
Note: You can download the Android NDK from http://developer.android.com/tools/sdk/ndk/index.html.

Activity Life Cycle Events and Threading

Android requires that all calls to OpenGL ES execute from a single thread because the EGL context can only be associated with a single thread and rendering graphics on the main UI thread is strongly discouraged. So the best approach is to create a separate thread specifically for all of your OpenGL ES code that will always execute from this same thread. If your app uses GLSurfaceView, it creates this dedicated OpenGL ES rendering thread automatically. Otherwise, your app must create the rendering thread itself.
The san-angeles and native-activity sample apps retain all of their OpenGL ES code in C, but san-angeles uses some Java and GLSurfaceViewto create the rendering thread and manage the Activity life cycle, but the native-activity sample has no Java code at all. Instead of usingGLSurfaceView, it manages Activity life cycle events in C and uses a rendering thread that the NativeActivity class provides. NativeActivity is a convenience class provided by the NDK that allows you to implement Activity life cycle event handlers in native code, such as onCreate()onPause(), and onResume(). Some Android services and content providers cannot be accessed directly from native code but can still be reached through the JNI.
The native-activity sample is a good starting point for porting OpenGL ES games because it demonstrates how to use the NativeActivity class and the android_native_app_glue static library to handle life cycle events in native code. These classes provide a separate rendering thread for your OpenGL ES code, a rendering surface, and a window on the screen, so you don’t need the GLSurfaceView or TextureView classes. The main entry point of this native application is android_main(), which runs in its own thread and has its own event loop for receiving input events. Unfortunately, the NDK does not provide a version of this sample for OpenGL ES 2.0, but you can replace all of the 1.1 code in this sample with your 2.0 code.
Apps that use NativeActivity must be run on Android 2.3 or later and make special declarations in their manifest file, as described in part 2 of this article series.

The Java Native Interface

If you choose to implement your app mostly in C/C++, it will be hard for you to avoid using some Java classes for larger and more professional projects. For example, the Android AssetManager and Resources APIs are only available in the SDK, and this is the preferred way to handle internationalization and different screen sizes, among other things. However, the JNI provides the solution because it not only allows Java code to call C/C++ functions but also allows C/C++ code to call Java classes. So, even though some overhead is associated with the JNI, don’t avoid using it completely. It’s the best solution for accessing important system functionality that’s only available in the SDK, especially when these functions are not performance critical. A full description of using the JNI is beyond the scope of this article, but here are the three basic steps required to make a call from Java to C/C++ using the JNI:
  1. Add a declaration for the C/C++ function in your Java class file as a native type.
  2. Add a static initializer for the shared object library that contains that native function.
  3. Add the function of the appropriate name following a specific naming scheme to the native source file.
Note: For more information on using JNI with the NDK, see http://developer.android.com/training/articles/perf-jni.html.

OpenGL ES 1.1 or 2.0?

So, which version of OpenGL ES should you target on Android? Version 1.0 of OpenGL ES has been superseded by version 1.1, so the choice is really between versions 1.1 and 2.0. Khronos and Google may support both of these versions indefinitely, but OpenGL ES 2.0 is superior to 1.1 in most ways. It is much more versatile and offers higher performance because of its OpenGL Shading Language (GLSL) ES shader programming features. It can even require less code and less memory for textures. But Khronos and Google still have at least one good reason for continuing to support version 1.1—it looks a lot more like the original OpenGL 1.x used in the desktop and console gaming worlds for decades. Therefore, it may be easier to port an older game to OpenGL ES 1.1 than to 2.0; and the older the game, the more likely that is to be true.
If the game you are porting has no shader code, then you have the choice of targeting either OpenGL ES 1.1 or 2.0, but version 1.1 will probably be the easier path. If your game does have shader code already, then you should certainly target OpenGL ES 2.0, especially when you consider that recent releases of Android now use version 2.0 predominately. According to Google, more than 90 percent of Android devices that have accessed the Google Play website have support for both OpenGL ES 1.1 and 2.0 as of October 2012.


You can implement graphics rendering on Android with OpenGL ES through the Android SDK, the NDK, or a combination of both using the JNI. The SDK approach requires coding in Java and is best suited to new app development, whereas the NDK makes porting legacy OpenGL code in C/C++ much more practical. Most game porting projects will require a combination of both SDK and NDK components. For new projects, OpenGL ES 2.0 should be targeted rather than version 1.1, unless your legacy OpenGL code is so old that it does not use any GLSL shader code.
Part 2 of this series will discuss the barriers that exist to porting OpenGL games that you must recognize before undertaking such a project, including differences in OpenGL extensions, floating-point support, texture compression formats, and the GLU library. Setting up your Android development system for Intel Atom processors and getting the best possible performance from the Android virtual device emulation tools with OpenGL ES will also be covered.

About the Author

Clay D. Montgomery is a leading developer of drivers and apps for OpenGL on embedded systems. His experience includes the design of graphics accelerator hardware, graphics drivers, APIs, and OpenGL applications across many platforms at STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX, and as an independent consultant. He was instrumental in the development of some of the first OpenGL ES, OpenVG*, and SVG drivers and applications for the Freescale i.MX and TI OMAP* platforms and the Vivante, AMD, and PowerVR* graphics cores. He has developed and taught workshops on OpenGL ES development on embedded Linux and represented several companies in the Khronos Group.

For More Information

Tuesday, March 4, 2014

Codeproject - Html5 Animations Using Canvas


Pros and Cons of HTML5 Cross-Platform Android* Mobile App Development Tools on Intel® Processor-based Devices

By 4 Mar 2014

Editorial Note

This article is in the Product Showcase section for our sponsors at CodeProject. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers.
The success of mobile applications depends on reaching target customers regardless of the device they use. And cross-platform mobile application development tools help developers do that. A typical customer might use an Android smartphone to access the Internet on the go, a Windows* PC at work, or an Apple iPad* in a café.
Instead of using complex technologies like Objective-C*, Xcode*, and iOS* APIs for Mac*, iPhone*, and iPad; Windows API, Visual Studio*, and C# for Windows PC; and Android APIs, Java*, and Eclipse* for Android smartphones, it is much easier and effective to use HTML5 cross-platform mobile application development tools. The key is to have the right features in your application that deliver a perfect user experience. Second, the app should have an inherent ability to work on new devices that continually hit the market.
HTML5, a markup language, has several features that allow it to run on devices specifically designed to consume less electricity. For example laptops, smartphones, and tablets have processors that consume significantly less power than desktop devices. It is the preferred markup language used today to structure and present content on the Internet.Strategy Analytics predicts that more than a billion HTML5 compatible devices will be in use worldwide by the end of 2013. HTML5 can be used to develop interactive web pages for deployment across multiple operating system platforms and browsers. Hence, cross-platform mobile app development tools based on HTML5 are appealing to mobile app developers.
<continued at main article>

posted under open source

Creating cool animations and transitions in HTML5 app for Intel Android devices

By 4 Mar 2014

Canvas Tag

One problem with earlier versions of HTML was the lack of multimedia techniques. You could not show a video or draw on the screen. With HTML5, new elements such as <video> and <canvas> have been released. These elements give developers the ability to use multimedia technology in "native" HTML, just by writing some JavaScript* in combination with HTML. A straightforward action that should be provided by multimedia technologies is animation, and now HTML5 has some ways to do it.
One of the most exciting features of HTML5 is the <canvas> element that can be used to draw vector graphics and engender astonishing effects, interactive games, and animations. The HTML5 Canvas is picture-perfect for creating great visual material that augments UIs, diagrams, photo albums, charts, graphs, animations, and embedded drawing applications. HTML5 Canvas works with JavaScript libraries and CSS3 allowing you to create interactive web-predicated games and animations.
The elementary code for using and setting a canvas looks like this:
<canvas id= "animation" width="150" height="150">

Sorry, your browser doesn't support the HTML5 element canvas.

This looks similar to the <img> element; the difference is that it doesn't have the src and alt attributes. The <canvas>element has only two characteristics: width and height. If your renderings seem inaccurate, try designating your width and height attributes explicitly in the <canvas> attributes, and not with CSS. The width and height attributes default to 300 and 150, respectively. The id will be used to initialize the canvas using JavaScript, and the text inside will be displayed as a call back when the mobile browser doesn’t support it.

Coordinate System

The prerequisite knowledge you need to draw on the canvas is the coordinate system. The canvas is constructed around the x and y coordinates. If you have worked with any other 2D graphics programming language, you already know the standard Cartesian coordinate system, where (0,0) is the top left corner. If we want to move a square to the right, we have to increase our x-axis value; if we wish to move up, we have to decrease our y-axis value. The diagram below shows how the x and y coordinate system is implemented.
The diagram shows a canvas area that is 200 pixels by 200 pixels:
  • The top left corner is x=0, y=0.
  • The x value increases horizontally, and the y value increases vertically.
  • The bottom right corner is x=200, y=200.
  • The center point is x=100, y=100.
We define the init method, which is used for initialization. The canvas is blank. To draw something, JavaScript first needs to get hold of the rendering context. To do this, the <canvas> element provides a getContext()method that captures the rendering context and its drawing functions.
    function init ()


    var cans document.getElementById("animation);

    var canctx = canvas.getContect(‘2d’);

The cans variable captures the canvas that we can draw the graphics objects on, and canctx holds the rendering context. In this case it is a 2D graphics object.
This context encompasses the methods for drawing on the canvas such as arc()lineto(), and fill().

Drawing Tools

The drawing tools for drawing on the canvas are:
  • Lines
  • Rectangles
  • Arcs
  • Bezier and quadratic curves
  • Circles and semicircles

Drawing lines

We use the beginpath() method to reset the current drawing on the screen. Then we use the moveto()lineto(), and stroke() techniques to draw a line on the canvas.
  • canctx.beginPath();
  • canctx.moveTo(x,y);
  • canctx.lineTo(x,y);
  • canctx.stroke(x,y);
The beginpath() method ensures that we are starting a new path. It begins another path, wiping out the present path (if any). If you discover you're getting an interfacing line in an animation from the start to the end of your path, it may be that you haven't used the beginpath() capacity to start your path/drawing. To make a way with HTML5 Canvas, we can associate different subpaths. The completion purpose of every new subpath turns into the new setting focus.
The moveTo() method sets the conditions for where the new subpath is to start. The lineTo() method generates subpaths. We can change the look of the line with lineWidth and strokeStyle. The lineWidth element modifies the thickness of the line, and strokeStyle modifies the color.
To create a line like the one shown above, we alter the code as below:
  • context.moveTo(50, 50) ‒ places the initial point for the path at (x=20, y=20)
  • context.lineTo(50,200) ‒ identifies the end point for the line
  • context.lineWidth = 10 ‒ the width of the line
  • context.strokeStyle = "#0000FF" ‒ the color of the line
  • context.lineCap = "round" ‒ makes the ends round
  • context.stroke() ‒ smears the line on the canvas
The three possible line caps are:
  • Context.round
  • Context.square
  • Context.butt

Drawing Rectangles

The three ways to draw a rectangular on the canvas are:
  • fillRect(x,y,width,height) ‒ draws a filled rectangle
  • strokeRect(x,y,width,height) ‒ draws a rectangular outline
  • clearRect(x,y,width,height) ‒ clears the given area and makes it fully opaque
All three types of rectangles are shown below.

Drawing a circle and animating it

In this section we will be generating a circle that moves about on the canvas. To generate the circle we will create adrawcircle function.
    function drawcircle(x,y)





The beginpath() method ensures that we are starting a new path. The arc(x, y, radius, startAngle, endAngle, anticlockwise) defines the size and shape of our circle.
The fill() method fills the circle with the color defined by the value of the fillstyle attribute of the context object.
To move the circle, we just need to alter the x and y values at a particular interval of time using the setInterval()method to the init function. Fundamentally we just redraw the circle. The animation is actually coming from thesetInterval method. The increment of the circle’s current position gives the effect of movement. Without changing the X and Y values, the circle would not move at all!
The setInterval() method requests a function or assesses an expression at definite intervals (in milliseconds).
If you execute the code, you’ll see a smooth moving animation of a ball leaving behind a trace. The reason for this is we do not refresh the frame and all the new drawing is added on top of the old. We will have to clear the frame every time the draw() function is called to hide this, the coolest (and fastest) way to do this is by just drawing a huge square on top of the whole canvas or by calling the clear function:
    function draw()


    canctx.fillStyle = rgb(255,255,255);

    canctx.fillRect (0, 0, 400, 400);

    if (x + dx > WIDTH || x + dx < 0)

    dx = -dx;

    if (y + dy > HEIGHT || y + dy < 0)

    dy = -dy;

    circleX += dx;

    circleY += dy;

    drawcircle(circleX, circleY);

Note: CircleX and CircleY are the X and Y positions of the circle, while dx and dy are the displacements with respect to the current position.
Transition is the procedure of altering from one form or situation to another. To add transition to HTML5 apps, we use CSS files. For instance, a lingering effect is instant on a link. With a transition, you can spread the extent of the advent of the change. This can be useful to draw attention to a particular part of the application.
Generally, when a CSS property value is altered, the extracted consequence is promptly rationalized, with the affected features instantly varying from the old property value to the new property value. This segment designates a way to stipulate transitions using new CSS properties. Using these properties, the object can be made to smoothly transition from one state to the other.


The transition-property line outlines which CSS property we want to change. The default value is ‘none’, which implies no transition. If we insert a value of ‘all’, all transition properties are applied.


The transition-duration property outlines the transition length. When the element changes to the original state, the duration echoes. We specify the duration in seconds (a number followed by an "s") or milliseconds ("ms"). The default is 0s.


The transition-timing-function property tells the browser the speed of the transition and how the speed changes over the length of the transition. The default value is ‘ease’. Other pre-defined values are ‘linear’, ‘ease-in’, ‘ease-out’, and ‘ease-in-out’.


The transition-delay property states the interval that occurs before the transition starts, that is, after a transition is prompted, the delay represents the time that lapses before any transition transpires.
    .example {

    transition-property: background-color;

    transition-duration: 5s;

    transition-timing-function: ease-out;

    transition-delay: 2s;


Transition shorthand

We can declare all of these properties in a single shorthand declaration. Consequently, we can prompt the above example as follows:
    .example {

    transition: background-color 5s ease-out 2s;

The authoritative ordinance of the time-cognate values is paramount. The first time value always represents duration, so if you want to include a delay, you must first define a duration.

Triggering a transition

Now that we know the syntax for CSS3 transitions, let us look at how to trigger them. The best way to trigger a transition is by using the: hover pseudo-class. The code for the: hover trigger might look like the following:
    .example {

    background-color: green;

    transition: background-color 5s ease-out 2s;


    .example:hover {

    background-color: red

If we hover over the element, the background color changes from green to red over a five-second duration, after a two-second initial delay.

Transitions triggered by events other than the: hover trigger

Triggering the transition is really not so much about the trigger itself (in the circumstance above, the trigger presence being: hover). What actually makes the transition happen is the transmutation of the element’s state.
There are number of ways apart from the "hover:trigger" to trigger a transition.Using: active
The: active pseudo-class characterizes the state that occurs when we click an element and hold the mouse button. The code might look like the following:
    .example {

    width: 200px;

    height: 200px;

    transition: width 5s ease-out;


    .example: active {

    height: 400px;

In this code case, the transition of the height property starts when we click and hold on an element, thus preserving the element's "active" state.
Some of the other pseudo-classes that we could use to trigger transitions are focus, checked. We could also trigger a transition with a combination of HTML5, CSS, and JavaScript and create wonderful mobile apps.

Other Related Articles and Resources

To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.
Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.
Copyright © 2013 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.
Test Your Apps on Intel Devices for Free
AppThwack lets you test your apps on hundreds of real, physical devices. Upload your code, run your tests, and get a report so you can address any issues before your users find them. Testing on Intel-based Android devices at AppThwack is free. Learn More.
To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)